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…