XmlRpcToWikiDiscussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories

So, I hope I didn't do too badly on my refactor hack job.

Since I've gone nutty the last few days and slapped XmlRpc interfaces on 3 WikiClones, I obviously like the idea. But before I go further into madness, one of the first things I'd like to pick brains about is WebDav vs XmlRpcToWiki, since while WebDav makes some intuitive sense to me as an API, it seems to be lacking in some important areas. I need to elucidate this thought some more.

For instance, one area in which a Wiki/WebDav solution lacks is in portability. In the XmlRpc implementations I've done so far, the interface is basically like any other CGI script. WebDav, however, requires one to have access to run a server or install extensions to a webserver. This sounds quite a bit more complicated and less likely to be widely adopted. (Assuming wide adoption of something like this is desirable.) -- LesOrchard

You only need the server extensions if you wanted to put WebDav support into the server. You can certainly use the protocol by parsing the protocol directly inside the script, or even a subset. For example, you could HTTP POST the stream to the CGI script. It's just data after all.

The point is mostly not to recreate the API used by WebDav when working on your own content management protocol. That way it's possible to adapt WebDav clients to the task as well as not making the same mistakes they did when creating their specification. -- SunirShah

I need to do some more WebDav homework. I was under the impression that Apache wouldn't let CGIs handle the expanded HTTP methods of WebDav, but I found at least one CGI-based implementation called WebRFM? (http://www.geocities.com/SiliconValley/Horizon/7772/webrfm.html) although it appears to have been languishing since the end of 1999. And from what you're saying, even if the HTTPd doesn't allow WebDav directly, I could try a kind of tunnelling between the WebDav client and a WebDav server behind a CGI POST. Not a completely unfamiliar pattern, given all the proxies and tunnels and carrier pigeons used in getting TCP/IP itself from place to place.

Definitely a good point about avoiding repeated mistakes by wheel reinvention. For some reason, though XmlRpcToWiki still seems like a good idea, if only because all the toy implementations I've done took almost no time at all beyond getting familiar with the particular WikiEngine. But, again, this may just be due to my need for homework and my recent mania over XmlRpc. -- LesOrchard

A few more thoughts on why I still think an XmlRpc interface is a good idea:

Non-exclusive.
- An XmlRpc interface doesn't rule out a WebDav interface.
Simplicity.
- I've got XmlRpc interfaces on 3 wikis in perl and python, and they're all < 250 lines including comments.
  - JanneJalkanen: Yes, the Wiki:JspWiki XmlRpc interface is roughly 400 lines, split between a servlet and a handler. Took me less than an hour to implement, and it included the time to download the Apache XmlRpc library and studying the API... :-)
- The interface shouldn't grow beyond 5-7 basic methods (not counting simple variants of the same method, ie. getPage vs getPageVersion) to cover the majority of actions a wiki user can take on a majority of WikiEngines.
Specificity.
- Not intended to become a broad CMS protocol, like WebDav.
- WebDav doesn't know about wiki. (ie. list links in a page? full-text searching? recent changes? [DASL] might cover this, but is unfinished.)

That having been written, I'm still playing with WebDav. --LesOrchard