Hello, I am a DWiki

DWiki stands for 'Dinky Wiki', which is what ChrisSiebenmann calls this for lack of a better name. As far as Chris knows on a casual scan, 'DWiki' is not being used as the name of any other Wiki software.

I (ChrisSiebenmann) wrote DWiki to have a good environment for writing documentation about how we do system administration work on our Unix systems. You can see a bigger list of Features if you want.

DWiki's design choices are very slanted towards making it as easy as possible for us to write, revise, and maintain system documentation. (Because on past evidence, it if isn't dirt easy we just aren't going to do it.)

I like WikiText, because it is a simple, low-effort way to write documentation that comes out looking decent. But I don't like the wiki interface for writing it: web browsers make crappy editing environments and limit the sort of changes you can easily do. So I wrote DWiki to have a good system for displaying wikitext that we'd write through other means.

Wiki or CMS?

Some people say (strongly) that DWiki is not a Wiki because people (currently) can't edit DWiki pages over the web; they argue that instead it should be called a CMS (a (web) Content Management System).

I'm willing to accept this argument in theory, but ...

I like punchy, usefully descriptive names. My personal opinion is that 'wiki' is one: calling DWiki a wiki tells you a great deal about it, while calling it a CMS tells you almost nothing.

So while I may be willing to accept the argument, DWiki stays being called a wiki (and keeps the 'Wiki' in the name).

I maintain web-based editing makes little sense for us, and wrote a bunch about why in WhyNotWebEditing.

And one can always have a big debate over at the granddaddy Wiki, at http://c2.com/cgi/wiki?WikiPrinciples.

(One comment.)

Why DWiki doesn't have web page editing

One of the signature Wiki features is that people edit pages over the web, often anyone and without restrictions (as the original Wiki was/is). It's said that this is a defining trait of Wikis, and that without it what you have isn't really a wiki.

DWiki has no from-web editing of pages. There are several reasons why.

Interface power

A web browser's form input text boxes are a totally crappy editing environment compared to what I have on a Unix system. Yeah, sure, I could require Javascript and load a huge editing library and maybe get somewhere, but a) I browse with Javascript off and b) am I going to get half as good as GNU Emacs or vi or sam? (I don't think so.)

So I want the primary way of editing DWiki pages to be from Unix, through the filesystem, with real editors. (And it is.)

Global edit doesn't make sense for us

The principles of global edit permissions leading to the world help write your pages simply don't make sense for us. DWiki's goal is to let us easily document how our Unix systems work. We're the only people who can write most of that documentation; outsiders can at best add side commentary.

This would be different if we were interested in running a Wiki on system administration best practices or the like. But we're not; we're just documenting our systems. We let other people read it so that they can learn from anything interesting we do (and that's primarily aimed at other people at the University of Toronto).

It's a drain we can't afford

Anything that allows semi-public writing on the Internet requires tending. Wikis are no exception to this rule.

Like many places, we are historically very bad at creating documentation. The more effortless I can make the process, the better the odds that we will actually write documentation.

Keeping DWiki running is part of the overall process; the less effort this takes, the better, especially if we aren't actively writing documentation at the time. Thus, I don't want DWiki to take up any time when we're not actively writing things with it.

If DWiki allowed web writing from anything except a small set of people, we would have to tend it. It is simpler and less risky to avoid that, especially given that we can't expect significant contributions from outsiders.

Skipping hard design problems

Eliminating web-based editing immediately kills the need to tackle a bunch of hard problems, because Unix handles them for me. Particularly, I don't need to authenticate people or do access control, provided I'm willing to let everyone read (I am, so far).

Access control, authentication, and registering people is not an easy area. It's also one where failures and program bugs can have severe consequences. Not having to worry about that means that DWiki is faster to write, smaller, and safer.

I also don't have to worry about random outsiders writing pages that make extensive use of expensive DWiki features, or writing things in pages that cause rendering errors.

But web editing can be done from anywhere!

Pragmatically, the odds of us wanting to edit our systems documentation from anywhere that we can't just run ssh to log in to our servers is fairly low. This is especially the case given that there are Java SSH applets, so that any browser that runs Java can let us log in to our servers.

DWiki is aimed at the low-hanging fruit of the 90% or 80% or so solution. (I maintain that any wiki is, partly because the text rendering is deliberately simplified.)

The future: maybe limited web editing

The most likely web editing feature for DWiki to pick up is to let web people write comments on pages but not edit the pages themselves. This would let outsiders give us feedback and commentary without running the risks of scribbling over valuable page content.

This would still require me to either write an authentication system or live with the likelyhood of comment spammers showing up to yammer madly. Plus some of the above worries.

(The clever person will notice that some of this future has arrived. DWiki now has an authentication system and comments, although both will be improved in the future.)

(2 comments.)

The code structure:

There's three chunks of code: the HTTP layer, the HTML view core, and the model.

The model deals with view-independant wiki level things, primarily retrieving raw pages and templates. (To do this it calls on a storage pools managed by a storage layer; the storage layer handles much of the RCS magic.)

The DWiki HTML view core gets a request context and is responsible for returning a response, whether that be rendered page content, redirections, or (rendered) errors. Renderers and template expansion are part of the HTML view core.

The HTTP layer is responsible for generating the request context, sending the response (including conditional GETs and other fun), and giving the HTML view core ways of generating proper URLs for given wiki pages.

The split between HTML view core and HTTP layer exists because the HTML view core is agnostic about how it is connected to the web, while the HTTP layer is intimiately tied to CGI-BIN versus Python BaseHTTPServer versus etc. So the HTML view core has everything that is web server independant.

FIXME: investigate this Python SCGI thing I've heard bits about. Or is that WSGI? See http://www.python.org/peps/pep-0333.html and http://wiki.python.org/moin/WSGIImplementations. Unfortunately on a preliminary look it seems I might as well write to CGI-BIN to start with.

I think that this is almost but not quite Model-View-Controller, but then I don't understand how MVC works (especially on the web).

To look at:

• http://java.sun.com/blueprints/patterns/MVC-detailed.html
• http://www.phpwact.org/pattern/model_view_controller

This suggests I am almost MVC except that my Controller is smeared over View code and that I have split the View into two pieces: the HTTP layer and the HTML view core.