The Butt Ugly Weblog

JSPWiki goes ~WebDAV and URI woes

I'm leaving for Japan tomorrow for about a week, so I'll post this here for the Great Internet Brain to munch on; it's not likely that I get much development done on the trip - heck, it's not even likely that I get my Powerbook back from repair shop before I leave...

I just yesterday committed an interesting patch to the JSPWiki CVS HEAD: it makes JSPWiki appear as a WebDAV repository. Once complete, this allows things like direct opening of attachments and saving them transparently into the Wiki, without the usual "click on link - edit - save locally - upload new revision back to wiki" -cycle, which can be very frustrating.

This is still an experimental feature (and will be disabled by default in the upcoming stable release), but it seems to work relatively well for browsing. It does not yet allow saving of documents, but that should be relatively simple to implement now that things are in place.

My big problem however, is not technical, it's more of an aesthetical nature (people who don't get how a technology problem can be aesthetical can go to the next blog now): what would be the correct URI space for the DAV support? The problem with DAV is the rendered content - all wikipages are dynamically generated, so the HTML is not a document that is editable.

At the moment, I have everything mounted under /dav (resulting in $blogurl/dav/raw/About.txt, $blogurl/dav/html/About.html for the raw wikimarkup and html rendered versions respectively), but for attachments the source and rendered versions are the same, so you could conceivably just inherit the ~AttachmentServlet from ~WebDavServlet and implement PUT, DELETE, MKCOL, PROPFIND and the rest of the bunch - GET is already done there! But that would result in a somewhat fragmented URI space: you could not just cut-n-paste an URL into a DAV client, since wikipages would need mapping, whereas attachments wouldn't...

Anyway, what is better?

Option 1)

Keep DAV URI space completely separate. The attachment handling is a bit complicated here; and the URIs have nothing to do with the usual browsing URIs.

$baseurl/dav/html/Foobar.html       = rendered page
$baseurl/dav/raw/Foobar.txt         = raw page in wikimarkup
$baseurl/dav/raw/Foobar-att/foo.png     = Foo/foo.png attachment

Option 2)

Use as much as possible the existing URI space (may result in confusion; very easy to do with attachments; has really no common "root" element).

$baseurl/wiki/Foobar.html           = rendered page
$baseurl/wiki/Foobar.txt            = raw page
$baseurl/attach/Foobar/foo.png      = attachments

Option 3)

Sorta like Option 2, but with differences (needs three servlets, perhaps the most configurable of all, but brings hassles, may not be intuitive to user).

$baseurl/html/Foobar.html           = rendered page
$baseurl/raw/Foobar.txt             = raw page
$baseurl/attach/Foobar/foo.png      = attachments

Option 4)

Something else - what? The comment area is open for suggestions...

(And yes, I wrote my own ~WebDAV library - I looked at Slide, as well as RFC 2518 and realized that I can probably write my own Class 1 DAV server in the same time that it takes for me to understand the Slide documentation. Boo hiss. And Slide is HUGE! It certainly suffers from a bad case of JAR-bloat'o'itis...)