blog.s11n.net

whiki: a “different sort” of Wiki back-end

Hi, all!

Despite the fact that the world has tons of wiki managers/back-ends, i felt compelled hack one of my own together. The initial inspiration for this came from the Fossil, an SCM which integrates source control, a wiki, and bug-tracking into a single application binary which can be used from the command line, a standalone web server, or as a CGI on an arbitrary web hoster. (i host many of my own projects using Fossil CGI over on fossil.wanderinghorse.net.) Through my use of fossil, i’ve come accustomed to maintaining non-API project documentation in a wiki, and love the ease-of-documentation this gives me (i’m a documentation maniac). Despite my love for fossil, however, i always felt that i was betraying the only wiki syntax i really like - the one used by Google Code. Since fossil doesn’t provide the features i need to replace its wiki handler with one of my own… you guessed it (or read it in the first line of this post)… i wrote a new wiki back-end.

In April i started work on whiki (the WanderingHorse.net Wiki), a “different sort” of wiki back-end, and it is now in a functional state (hosting three live wikis as of 17 May 2011). Like most wiki back-ends, it uses a database (sqlite3 or MySQLv5) to store its pages. What differentiates whiki from other wiki back-ends is:

• It is implemented in C and runs as a CGI application (or, to some degree, from the command line). i’m not personally aware of any other wiki manager/back-end implemented in C.
• It consumes and produces only JSON data. Requests are sent in the form of simple HTTP GET or (for more complex requests) POST requests (with JSON payload data) and responses are in the form of a JSON object tree.
• It has no “native” wiki format. Instead it tags each wiki page with a “content type” label (e.g. “text/plain” or “wiki/googlecode”), and applications can use that hint to determine how they should render a given page. Client applications can, with little effort, support multiple content types in the same logical wiki (e.g. plain text, source code (to be syntax-highlighted by the renderer), HTML, or even multiple wiki formats).
• It has no “native” user interface. UIs can be written using client-side languages like JavaScript, Java, or PHP, which interact with the whiki back-end via JSON messages. The main whiki website is implemented entirely in JavaScript, CSS, and HTML, and primarily uses the wikiwym GoogleCode-syntax wiki parser for rendering its pages (but it also supports several other content types).
• It allows clients to attach arbitrary JSON data to each page. This can be used for any number of things, e.g. implementing “tags”, marking certain pages as “featured” or “important”, defining intra-page relationships (e.g. for rendering a hierarchical menu), or flagging a certain page as the “home page.”

whiki is not, and will never, be an industrial-strength back-end like the one used to power Wikipedia (or any number of other large wikis). It is intended to supplant my fossil-based wikis (meaning anywhere from 5 to 20 pages or so). It is also missing some features which would certainly be of critical importance to many potential users. e.g. it has no search functionality, only two access levels (all or nothing), and has no support for storing historical versions of each page. (With another contributor or three we could fix those shortcomings, but i personally have relatively little need of them.)

If the following applies to you:

• You’re an eccentric C hacker who wants to host his own small wiki but doesn’t want to use PHP or…
• You’re a lone hacker who wants to an easy way to host wiki-style documentation for one of his pet projects or…
• You currently use Fossil but aren’t quite satisfied with its wiki

… and you have the ability to compile and run C applications on your web hoster…

Then whiki just might be slightly interesting for you:

http://whiki.wanderinghorse.net

Happy Hacking!

—– stephan beal