A good WikiEngine
acts like a WikiServerEngine
to HTML-rendering, HTTP-talking web browsers. It performs the following functions:
Right now, most WikiServerEngine
s perform those four functions somewhat monolithically. I propose a new standard architecture that divides the work a bit:
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:
- better interoperability between WikiServerEngines
- ability to write specialized clients with better WikiNavigationFeatures?
- WikiServerEngines that specialize in data storage won't get bogged down with page formatting
- having a protocol layer as well as an API layer would facilitate mixed-language WikiServerEngines?s (e.g. WikiRawDataToHtmlConversion? and WikiNavigationFeatures? in Perl; WikiRawDataStoreManagement? in C++)
- easier to build a WikiFireWall? for outside world
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?
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:
Breaking out APIs facilitates writing utilities. Examples:
- A) Want read-only HTML snapshot of Wiki to write on CD and send to somebody
Use APIs #1, #2, and #3
- B) Want to identify complex topological phenomena in Wiki using nightly process (such as orphan pages, knots)?
Use API #2
- C) Want to have a special plugin that does raw data storage into a source control system
Use same API #1, but replace internals with more sophisticated implementation.
Use same API #3, but write new plugin for other WikiLanguage
- E) Want to front end Wiki pages that live on another server.
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.
See also: StorageLinkingPresentation