Programming Projects

You asked for it! (Ok, maybe you didn't)

Sunday, September 7, 2003

WikiRpc Blathering v0.1

In this post I mentioned three primary architectural divisions for wikis: Presentaion, Functional Rendering, & Repository Management. I went to bed thinking about the WikiApi question. If we want to provide an API into a wiki, where would we put it? What is the appropriate point to split the semantics apart into multiple tiers? There's no real clear answer to this because it's so dependent on a currently fluxuating usage model.

Then I came across the WikiRPC interface spec over at JSPWiki.

[Note: In the interest of not salting the dig I'm playing with this in my head and here before getting involved with the discussion over at JSPWiki intentionally.]

As a thought exercise more than anything else I decided to see how easy it would be to categorize these methods. These are loose classifications based more on the architectural component that needs to handle the request.

So here goes:

Repository management:

getRecentChanges (depends on how it's implemented unfortunately)
getAllPages
getPageInfo
getPage
getPageVersion
putPage
listAttachments
getAttachment
putAttachment

Functional Rendering:

listLinks
getBackLinks

Presentation:

getPageHTML
getPageHTMLVersion

Introspection (in addition to standard xmlrpc toys):

getRPCVersion

They actually classify pretty solidly. Most of the methods are related to repository management and could probably be snipped out and replaced with any document management system worth it's salt in short order.

An important aspect of this model of wiki functionality is the existence of a progressive but nonlinear dependency chain. The Content Management can exist in isolation. Functional Rendering must depend on a CM component and the Presentation layer depends on both. It works, but I'd probably design it differently if it were mine to design.

Paring it down:

I think this api could be thinned out considerably with the addition of one primitive: getWikiwordRegex

If you added that, then you could homogenize the Repository Management interface down to simple methods that would definitely occur in any reasonable content/document management system.

Concerning the attachments methods: I need to learn more about how they actually differ from other pages (are they merely forced links to "pages" that contain raw content?) before I can figure out how to pull them out.

The value-add methods that relied on the Functional Rendering semantics could be performed by another discrete component OR by the client itself, opening the door to creative interpretations of how the semantics of wikiness would work for an individual repository.

I've got an eye towards using an API as a mux/demux for a client to interrelate multiple disparate repositories. Many of them have subtly different rules on wikiwords.

Wiki Markup

Then there's the morass of wiki markup. There's GOT to be something that can be done (regardless of whether or not it SHOULD be done) to programatically access wiki markup rules. Of course a standardized markup system would be optimum, but I'm not about to propose that as a reasonable solution.

The line-centric formatting of wiki markup is strong enough that this could be a reasonably easy thing to do.

What would I add?

That's easy:

Multi-repository support (NOT implicit cross repository support.) so that a service provider could host multiple wikis.
User authentication (for the same reason AND to lock out trolls and spambots.)
Split "attachments" out into a value-add component. Get it out of the core.

Don Park mentioned in an "in passing" sounding way, the possibility of using/adapting a weblog api for wikis. This could substitute the content management layer, but the higher level semantics just aren't there at that level (unless you started farting around with merging in the trackback api (which I'm remarkably unfamiliar with) as a linkage management system.)

You're it.

UPDATE: It occurs to me that it's easy to misread my intent here. All that "yeah it can be abstracted into the content management interface" isn't to imply that it can be dispensed with, but that it can be abstracted and well encapsulated.

2:50:50 PM

comment []