WikiWikiTransportProtocol

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Right now the most common Wiki Architecture is as follows:

 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

Or:

 WikiClient = Wiki search engine
 Transport = WWTP

Or:

 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 :)

--KornelLesinski

You might like to check out the XmlRpc interface for a working WWTP-like API --LesOrchard

You more likely want to check out WebDav, the W3C standard. (Hint, hint. ;) -- anon

Same here, WebDav was and is planned for MoinMoin; the major benefit being standard clients, with possibly some more work in programming on the server side. -- JürgenHermann

Two not-so-radical questions about Wiki:

Why not CacheHTML?
Why not use RawMode?

Just some thoughts I've had about next generation wiki --anon.

See the relevant pages, and then please delete this text when satisfied.

: not exactly what I meant, and I don't like being anonymized -- TarQuin

[CategoryWikiTechnology] [CategoryUnimplementedWikiTechnology]

WikiWikiTransportProtocol

Discussion