Wiki Wish List
Hokay, so: there
are these things called “wikis”. It’s a contraction of WikiWikiWeb. I’ve mentioned wikis here several times before.
The basic idea: collaborative websites, editable within the browser.
Dead-easy markup; no HTML required. Cross-referencing is a snap.
This sort of site comes in extremely handy for community websites,
knowledgebases, intranets, etc. I’ve built a couple for use at work, and
I keep seeing new opportunities to apply the approach elsewhere.
The thing is, there are approximately one jillion different
breeds of wiki software out
there (still more!). It’s sort of the “hello world” of
content-management systems; everyone interested in this sort of thing
implements (at least) one.
And I can see why: every existing implementation seems “broken” to me
in some way. This is a purely personal and qualitative assessment, to
be sure, but I’d like to think that my requirements are really pretty
reasonable…
- The wiki markup ought to be sensible, consistent, and
easy on the eyes; being a little bit extensible wouldn’t hurt.
Problem: most wikis are spiritually entangled with the original wiki
syntax, which is a shambles of ticks, stars, brackets, equals signs,
hyphens, and other unpleasantness. I want fewer special characters,
used in predictable ways. [Update: There are some really solid
ideas along these lines in the Wikitax proposed syntax
over at MediaWiki; of course,
there are some other parts that are truly insane (look at the
unnecessarily-complex [>>> block-quote |] syntax).] - Closely related is linking syntax; once again, being
shackled to the original syntax hobbles most wiki engines here. The
bizarre adherence to CamelCase is not only a
blight on English prose, it’s downright incompatible with non-Roman
language scripts. Fluid syntax for “free links” (those with spaces
and non-Latin characters) is a must (and the URLs for those
ought to be reasonable, too; turning “Some Page” into “Some+Page” is
reasonable; “Some%20Page” is barely acceptable (because a browser
will perform this conversion automatically); “Some_20Page” is just
gross). - It has to be implemented in a reasonable programming
language; “reasonable” is defined here as “one which will allow
the programmer some measure of self-respect”. This excludes Perl
straight off, most likely PHP, definitely VB/ASP. The
reason for this requirement is that I will want to write my own
macros, and I want to write them in something other than line
noise. - It has to support custom macros. See above. Local
wiki-syntax modifications as pluggable macros also a plus. - It must be fast. Page caches are a minimum requirement;
indexed searching is a plus. - It must support users and permissions (ACL or groups or
whatever). - It must support page versioning.
- It must run as a CGI. Seriously, who out there thinks
they can write a better web server than Apache? Look, if you think
it’s a good idea to run an httpd inside your wiki software just so
you wont’t have to think so hard about persistent state, stop
now. - It must have robust attachment support. This pretty much
boils down to “snappy image handling.” - It must have some metadata support. Look, I love MoinMoin, but the only way to
express anything like metadata is with a page link. This buys you two
set-membership operators: links-to and is-linked-from.
That’s it. You can express categories this way, and parent/child
relationships, but there’s no way to establish arbitrary (scalar)
properties for a page. Linking is the only hammer that most wikis
have, and atributes like author-of or date-of can not be
represented as nails.
My final requirement: it must be a maintained project. This is
why I’m not planning to go out and write my own any time soon; unless
I’ve got enough time on my hands to make it a full open-source project,
and to coordinate its ongoing development, I will be the only person
capable of maintaining a wiki engine of my own design.
Now, if I could wrangle this into a research topic…