Hello, (01)
My friends and I (www.canonical.org) have been playing
around with a PurpleWiki installation on our joint machine.
One of my friends, Jason Cook, recently wrote perplog which
he mentioned on this list and I recently finished a command
line tool to manage PurpleWiki nodes. (02)
The program requires local filesystem access to the Wiki
Database and read/write/access permissions. To make the
permissions work I added a Umask option to the PurpleWiki
Config.pm and then added a line at the beginning of wiki.pl
that sets the umask (diffs attached, they patch cleanly
against a Feb. 1st version of 0.9.1). (03)
The problem was that the wiki.pl program was setting
only write permissions for the owner. My changes allow a
more flexible umask and as a result I was able to get
things to work in my particular situation. The umask we use
is 0002. YMMV. (04)
The program I wrote, manage-wiki-node, allows you to
edit, retrieve, update, create, and test nodes for
existence. It doesn't do any transclusion stuff, because
it's only meant to handle nodes. The motivation for this
program was to have a update-wiki-on-CVS-commit program, so
I figured to be able to do that we needed something like
manage-wiki-node. I haven't written the update-on-commit
program yet but it should be trivial now with a functioning
manage-wiki-node. (05)
Since timestamps are used to detect conflicts when
editing Wiki nodes the program had to take this into
account. The result was two options: -e and -u. -e writes
out the WikiText content of a node with the first line being
the node's timestamp as it's saved in the WikiDB. The -u
option reads in WikiText (presumably edited from the
previous content) with the first line being the timestamp as
was returned by -e. If the node's current timestamp is
different than the one on the first line of the input to -u
than a conflict is detected and we bail (no conflict
resolution is done). (06)
Since dealing with timestamps can be a pain I wrote a
wrapper around manage-wiki-node called edit-wiki-node that
handles all the timestamp management and then invokes
$EDITOR on the node's content (which is saved in a file in
/tmp). After editing is done the changes are saved (or not
saved if there were no changes) and the temp file is
removed. If the Wiki node doesn't exist than edit-wiki-node
will invoke the editor on an empty file, as you would
expect. (07)
Neither the node manager nor the node editor allow for
minor edits, previews, or email notification. Also, the
summary info for RecentChanges has to be supplied on the
command line which is counterintuitive. As is the -f option
for the node manager which is used only to supply an input
file name and has no effect for saving output (output is
always written to STDOUT). Also, the node manager uses
a hard coded userID of 3307 (more on that below). (08)
I realize that editing and managing nodes from the
command line isn't that useful when you are restricted to
the same host as the Wiki. So I have made some early
attempts to wrap up my efforts in SOAP so as to have remote
access. (09)
I am very new to SOAP. My initial idea was to wrap all
of PurpleWiki in SOAP but after seeing thousands of lines of
XML flash across the wire on a simple PurpleWiki::Config
instantiation, I figured maybe that wasn't a good idea. So
I hacked manage-wiki-node to be a module. (010)
The module only has one public routine, runMode(), which
takes as its argument a list of command line options
(ideally it would take @ARGV as its argument). Then I wrote
a small server and a simple client that just passed in its
@ARGV to runMode(). Everything worked, I was happy. (011)
The SOAP hack doesn't allow for reading from a file, nor
does it address the needs of edit-wiki-node. I think both
of those things are just a matter of programming. I think
wrapping manage-wiki-node in a module (rather than have it
be a stand alone script) cuts down on the amount of SOAP
talk that needs to happen, but I maybe wrong -- I don't
really grok SOAP. However, I think I have gotten far
enough along to say that my SOAP hack is a proof of concept
for having a remote version of manage-wiki-node. (012)
Anyway, I have a question about user IDs. Can someone
explain the username/userID system to me? It seems that
userIDs are a dime a dozen and serve no important purpose
other than to act as cookie trackers. As a result I just
hard coded 3307 as the userID for the node manager and I am
unclear if this is Bad, Good, or just merely Ugly. If I
understood the userID system better I think I would know the
Right Thing to do. (I do understand the userID assignment.
I just don't understand their function.) In other words,
how should my program determine its userID? Get a new one
every time, use a hard coded one (i created a userID for it,
this is what I am doing now), or something else? (013)
I also was wondering if someone could explain the
KeptRevisions data structure. It seems to be a list of old
sections, but I haven't looked at the code deeply enough
to understand what's going on here. (014)
The reason I am wondering about KeptRevisions is that I
noticed a bug regarding them in (at least) version 0.9.0 of
the PurpleWiki. If you click the "View other revisions"
link on a new node (one that has no previous revisions) then
you get the following error: (015)
Can't use an undefined value as an ARRAY reference at
/usr/local/share/perl/5.6.1/PurpleWiki/Database/KeptRevision.pm
line 66. (016)
If you go to the following URL you can witness the bug in
action (this won't work if someone edits the POE node): (017)
http://wiki.simpleideas.org/index.cgi?action=history&id=POE (018)
My umask() patch to wiki.pl also includes a patch to fix
this bug, but I am not certain it is the Right Way to fix
things, mostly because I am not certain of how Kept
Revisions work. It does appear to make things work again,
but only for new nodes. Nodes created before the fix will
still have this bug. (019)
My patch for wiki.pl (works as of the Feb 1st version of
0.9.1) is attached to this email. The patch for Config.pm
also includes Jason's patch for the HttpUser/Pass thing,
since we're using the same Config.pm. The tarball for
manage-wiki-node and the node editor is here: (020)
http://panacea.canonical.org/~matthew/manage-wiki-node.tar.gz
(I think edit-wiki-node only works after make install, IIRC) (021)
The README which explains how to use the program is here: (022)
http://panacea.canonical.org/~matthew/README.html (023)
I haven't included any links to my SOAP work, but I can do so
if anyone is interested. It's not very profound, it just
turns manage-wiki-node into a module and then includes a
textbook SOAP client and server. (024)
I hope someone finds this stuff interesting. I also
hope someone doesn't reply and tell me I completely
misunderstood the fundamental mechanics of something or
other and invalidate my entire approach to command line node
management. (025)
-matthew (026)
wiki.pl.diff
Description: Text document
Config.pm.diff
Description: Text document
pgp00000.pgp
Description: PGP signature
|