A good WikiEngine acts like a WikiServerEngine to HTML-rendering, HTTP-talking web browsers. It performs the following functions:
WikiRawDataStoreManagement
WikiLinkDetection
WikiRawDataToHtmlConversion
WikiNavigationFeatures
Right now, most WikiServerEngine**s perform those four functions somewhat monolithically. I propose a new standard architecture that divides the work a bit:
WikiRawDataStoreManagement
WikiLinkDetection
(api/protocol separation)
WikiRawDataToHtmlConversion
WikiNavigationFeatures
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 WikiServerEngine**s
- ability to write specialized clients with better WikiNavigationFeatures
- WikiServerEngine**s 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
-- 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:
- 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.
- D) Want to support another WikiLanguage.
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.
-- SteveHowell
See also: StorageLinkingPresentation