WikiClient = HTML Browser Transport = HTTP WikiServer = CGI program or some kind of servlet Database = back-end abstraction with no protocol for direct access by the WikiClient
I suggest that a standard WikiWikiTransportProtocol (WWTP) would allow for greater flexibility. WWTP would probably run on top of sockets just like HTTP. A good WikiServer would support WWTP to allow for smart WikiClient's. Example:
WikiClient = smart Java program Transport = WWTP WikiServer = Perl program listening for WTTP requests Database = bunch of files in file system
WikiClient = Wiki search engine Transport = WWTP
WikiClient = web browsers outside of your company Transport = HTTP WikiGateway = CGI program that sends WWTP request to internal Wiki and disables edits Transport = WWTP WikiServer = your internal Wiki
Why create new protocol? HTTP is extensible enough and widely supported. You get goodies like proxying, caching, transfer-encoding (compression) "for free".
...unless you'd like to have realtime-updated cooperative edits of pages, which would require persistent two-way connections (naaah :)
You more likely want to check out WebDav, the W3C standard. (Hint, hint. ;) -- anon
Two not-so-radical questions about Wiki:
Just some thoughts I've had about next generation wiki --anon.
See the relevant pages, and then please delete this text when satisfied.