The DAVWiki – next step of WikiRPCInterfaces?

Janne Jalkanen

http://www.jspwiki.org/

Nokia Corporation

What is JSPWiki?

Java / J2EE / JSP -based WikiEngine since 2001

Very plugin/module -oriented

PHPWiki markup variant, embedded CSS

No SQL needed

Under active development

Designed to be quite customizable

Clean code base, easy to modify

Popular with corporate intranets

IBM, Sun, Oracle, BaseN, US Dep. of Agriculture

http://jspwiki.org

Why RPC, we've got the browser?

Yes, but the HTML is designed for people, not machines

Programmatical access to WikiPages is very useful, both rendered and WikiMarkup

e.g. JSPWiki mail notifier – done 8000+ km away!

Allows scripting on the page data

Ease maintenance work

No need to upgrade server software

Modularizes structure

Reduces load on server (no HTML scrapers)

No need to open database to third parties

State of the Wiki RPC

Original JSPWiki API

Written in 2002

Several drawbacks

Designed to be generic; ported to several engines

VoodooPad API

TikiWiki API

MediaWiki Special:Export

Uses own schema, MediaWiki-specific

None of these could be called successful!

What about Atom?

Yes, Atom Publishing Protocol could be used

Atom is RESTful; XML-RPC is, well, RPC.

However, Atom is mostly designed for weblogs and publishing; it needs extensions to support wiki specifics

Many of them could be lifted from RSS 1.0 though

However, WebDAV is supported by many OSs already

Advantage: Atom documents can contain a <link> element to the API endpoint

Allows more leeway in design

Practical problems in using RPC API

WikiMarkup, WikiMarkup, WikiMarkup

We all have our favourite variants

No luck in standardising on a single markup

Wiki Special Pages

e.g. RecentChanges

Different wikiengines, different special pages

Rendered Wiki pages

CSS, HTML fragments

Page locking & concurrent changes

Page versioning, diffs

What is WebDAV?

HTTP Extensions for Distributed Authoring

Aka RFC 2518

Simple extensions to HTTP

Use GET to get file, use PUT to add a new version, DELETE to remove

Just like HTTP, but also well-defined semantics for collections

New HTTP verbs:

PROPFIND: Find metadata about a collection or a file

PROPPATCH: Change metadata

MOVE: Move a file

COPY: Copy a file

LOCK, UNLOCK: ...well, take a guess :)

A practical example

GET /index.html

OPTIONS /index.html

HTTP/1.1 200 OK
DAV: 1
Allow: GET, PUT, POST, OPTIONS, PROPFIND, PROPPATCH, MOVE, COPY, DELETE

PROPFIND /index.html

HTTP/1.1 207 Multistatus
<multistatus xmlns="DAV:”>
<response>
<href>http://localhost:8080/JSPWiki/dav/</href>

<propstat>

<prop>

<getlastmodified>2005-07-28T00:30:18+03:00</getlastmodified>

<getcontentlength>0</getcontentlength>

<resourcetype><collection /></resourcetype>

</prop>

<status>HTTP/1.1 200 OK</status>

</propstat>

<propstat>

<prop><getcontenttype /><lockdiscovery /></prop>

<status>HTTP/1.1 404 Not found</status>

</propstat>

</response>

Advantages of WebDAV?

IETF standard

Directly supported by Mac OSX, MS Office, KDE, etc

Implementations available (e.g. Jakarta Slide)

Does not care about content types

Media, attachments, wikimarkup, HTML – all treated the same

Works on standard HTTP by extending it

Can be added to any resource which has an URI

Filesystem model: yeah, you can “grep foo *”

Use scripting on WikiFiles without bots or HTML parsing

Get rid of the “download attachment, edit, save locally, upload” -cycle

Issues with WebDAV – directories

A PROPFIND on a directory lists files

But a Wiki has a flat name space

Therefore only one directory – which will be very, very big to fetch (especially in XML)

Subdirectories: DAV spec suggests

/a/ATestPage, /c/CommonCold, /r/Rabies

Maybe even /a/at/ATestPage, /c/co/CommonCold

This will break the 1:1 mapping of DAV urls and normal wiki URLs!

Issues with WebDAV - complexity

In fact, DAV is a rather simple protocol

The complexities are in certain header handling

Versioning/authentication brings in extra complexity (and a bunch of new verbs)

However, a WebDAV Class 1 needs to only implement

GET, PUT, PROPFIND, PROPPATCH, MOVE, COPY, OPTIONS, DELETE

Some header handling

Issues with WebDAV – access control

Doing a “delete all” is as easy as “mount http://wikipedia.org /opt/wikipedia && rm -rf /opt/wikipedia”

Even the dim-wittest script kiddie can do it

So perhaps some form of control might be useful

You can use HTTP Basic

But WebDAV does have its own auth system as well

RFC 3744

Issues with WebDAV – Special Pages

Proposal: special directory (call it “System”)

RecentChanges: System/RecentChanges.atom, a read-only XML file

Yes, adopt Atom 1.0 for RecentChanges

Other alternatives:

RSS 1.0 with Wiki extensions

Similar approaches for other files

Still... what to do with searching?

Issues with WebDAV - Versioning

Versions are integral to Wiki

Un-defacing, edit wars, despamming

However, in intranet use not that important

WebDAV defines its own versioning scheme

RFC 3253

Adds a bunch of new methods

Not all of them useful in a wiki, though

Not necessary to implement them all either

Issues with WebDAV - rendered content

GET /wiki/TextFormattingRules

Fine, you get the rendered HTML

But you do get all the headers and footers, too

GET /dav/raw/TextFormattingRules.txt

Hey! It's in WikiMarkup

GET /dav/html/TextFormattingRules.html

Rendered content without the headers

How do you know how to get the raw content from the base URI?

You don't... It has to be by common agreement.

Or perhaps a custom PROPFIND attribute

PROPFIND on all these results is subtly different

e.g. length, mime-type

Wiki Markup Mess

Every single WikiEngine has its own standard

Some major strains exist (Kwiki, PHPWiki, Mediawiki)

All attempts at consolidation failed

Together now: “We're all individuals!”

A secret: Users hate this. Especially corporate users.

Wiki Markup Mess – why not...?

Just Let It Be

Wikis already use a common standard: (X)HTML

Common users don't care about plugins, snips, templates, what-have-you

Solution: implement XHTML import

(Metadata not really a problem: people are very good at defining ontologies already)

JSPWiki and WebDAV

JSPWiki supports WebDAV at <wiki url>/dav/

Two directories /dav/html/, /dav/raw/

PDF content could be similarly available

Can be mounted
directly in OSX

First letter separation

/dav/html/a/

Custom DAV
implementation

JSPWiki and WebDAV, continued

Attachments, however, are still located in the standard wiki URL /attach/

Discrepancy needs to be solved – ideas? :-)

Problem: WebDAV client implementations inconsistent

Saving works with Goliath and DAVExplorer, but not OSX - eh?

Conclusions

WebDAV could fulfill the role of the Wiki API

No need for a common WikiMarkup – use XHTML in, XHTML out

Custom XML elements can be added for specifics

RDF/XML for metadata?

JSPWiki implementation still shaky...

But then again, Slide needs many dependencies

Thank you!

Questions?

Janne.Jalkanen@nokia.com (work)
Janne.Jalkanen@jspwiki.org (private)

2005-08-04T00:17:40