You asked for it! (Ok, maybe you didn't)
||Sunday, September 7, 2003
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:
- getRecentChanges (depends on how it's implemented unfortunately)
Introspection (in addition to standard xmlrpc toys):
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
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
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.
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?
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.)
- 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.
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
© 2003 Michael Wilson
Last Update: 10/26/03; 19:35:13