dwiki: Recent Entries For 2005/05/27

Subdirectories: NewFeatures.

2005-05-27

DWiki, 19:46:34 by cks

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.

DWiki now supports comments on pages; comments are themselves written in DWikiText. Currently pages have to be specifically enabled for this; in the future I will have a better global or semi-global mechanism for this.

Read more »

Written 19:38:55 by cks.

WhyNotWebEditing, 19:21:10 by cks

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

As part of the fallout of other work, I fixed the nit where 'View Source' would show as a page tool on pages where viewing the source would get you a permission or unavailability error.

Written 15:19:03 by cks.

With blog-style things now decently supported, there is the problem that some pages want to be longer than is comfortable for display in a blog setting. Now wikitext can signal that only the front should be shown in some contexts, like so:

Read more »

Written 01:03:10 by cks.

Directories can now have default view types associated with them, by the simple yet sleazy method of touching a file in them called .flag.prefview:<viewname>.

This lets us auto-set a directory to default to a blogdir view.

The page tools now autogenerate a list of 'See As <whatever>' links for alternate directory formats.

This required some innards magic to distinguish a normal view being explicitly specified from no view being specified and us just defaulting to a normal view.

Written 00:33:43 by cks.

(Previous day | Next day)
By day for May 2005: 24 26 27 28 29 30 31; after May.

Page tools: See As Blogdir, See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.