Wiki Server Architecture

A good WikiEngine acts like a WikiServerEngine to HTML-rendering, HTTP-talking web browsers. It performs the following functions:


Right now, most WikiServerEngines perform those four functions somewhat monolithically. I propose a new standard architecture that divides the work a bit:

 (api/protocol separation)

There is no reason to lock a WikiServerEngine into a particular storage paradigm. You might want to have two versions of a WikiServerEngine. Both versions would have the same formatting/navigation features, but one might have high-performance WikiRawDataStoreManagement? for heavy-traffic sites, while another version would have a lighter solution.

More importantly, dividing up the responsibilities like this within particular WikiServerEngine implementations paves the way for the following advantages:

-- SteveHowell

This architecture would certainly make sense for some needs. But making it the "standard wiki architecture" might not be appropriate. I'm not sure a general need for this additional API/protocol layer has been demonstrated. One nice thing about wikis is that their implementations are simple. DoTheSimplestThingThatCouldPossiblyWork. I see "you might want" this and that this "paves the way" for future functionality, but can you show some evidence that this sort of refactoring would simplify existing wikis? --KrisJohnson

I hacked up my copy of PikiPiki recently to allow multiple folders. PikiPiki is extremely clean code, but it didn't really separate the data-store functions from the page-delivery functions with any API/protocol layer. My changes to support folders ended up being pretty pervasive. So, this would be a case where refactoring would simplify an existing wiki.

More importantly, though, I want to interoperate with other Wikis. When I add cool navigation features to my Wiki, I want to use those features to surf other Wikis. Right now, most Wikis only have a proprietary HTTP interface, and it is awkward to get just the raw pages from the Wikis. If other Wikis supported a protocol layer to their WikiRawDataStoreManagement? and WikiLinkDetection? features, I could easily front end other Wikis. -- SteveHowell

At least break out the APIs

At the very least, a good Wiki should have four separate APIs:

 1) WikiRawDataStoreManagement? 
 2) WikiLinkDetection?
 3) WikiRawDataToHtmlConversion?
 4) WikiNavigationFeatures?

Breaking out APIs facilitates writing utilities. Examples:

Use APIs #1, #2, and #3

Use API #2

Use same API #1, but replace internals with more sophisticated implementation.

Use same API #3, but write new plugin for other WikiLanguage

Use APIs #1 and #2, but have them call standard WWTP protocol to interact with other Wiki.

Finally, let's say you want to develop an intranet WikiClient that lets users edit pages in a more seamless way than browsers provide. It would be nice not to have to reinvent the WikiRawDataStoreManagement? mechanism. You would only write the client features, and you would talk to the existing WikiRawDataStoreManagement? mechanism with the standard protocol.

-- SteveHowell

See also: StorageLinkingPresentation

View edit of August 28, 2009 or FindPage with title or text search