paperlined.org
dev > perl > web > nanowiki
document updated 13 years ago, on Jul 14, 2011
The popular definition of a "wiki" includes a number of features that aren't absolutely needed in every situation. If these semi-optional features can be identified, and they're removed from the requirements depending on specific situations, then it may be possible to implement the wiki with far less code.

Wikimatrix.org is a really fantastic catalog of extant wikis, that lets you search on these specific features.

No database, use only flat-file storage

It may be possible to store each page as an individual file on the filesystem, and not use a database at all. Rather than use a specialized on-disk datastructure to access our data (e.g. B+ trees), we rely on the OS's filesystem code to organize our data.

This can have a severe performance impact, as database indexing is unavailable. However, if the site has very few visitors, this may be an acceptable simplification.

Related WikiMatrix fields:

Remove the ability to change content from the browser side, server-side changes only
AKA: Democracy ⇒ Oligarchy

If you remove the ability for users to make modifications to wiki pages from the browser [client] side, and instead require updates to be done via SSH + vim (or similar editor), this simplifies the implementation signficantly.

The webserver is now read-only. The webserver no longer needs to track users or do authentication — user-authentication and write-permissions are handled by the OS instead.

This makes the wiki far less democratic — only a few people will ever have the ability to edit the site. However, for wikis that you know, up front, will only ever need to be modified by a small group of people (thus the term "oligopoly"), this is an acceptable simplification.

Don't do any versioning (no history or diffs)

If we stop storing previous versions of each page, and ONLY store the latest version of each page, then this simplifies the implementation somewhat.

There is a signficant downside to this — readers no longer have any idea of what changes caused a page to appear on the recent-changes list. The triggering change could be quite small (eg. adding/removing a space) or quite large (eg. the page was just created, and contains a lot of text), they have no idea. If you have any readers at all, this may annoy them quite a bit.

However, this may be an acceptable comprimise if you're trying to implement the most minimalistic of wiki engines. In most cases, you could leverage off of existing versioning code (such as using Git or Hg), so the code overhead is not very great. Nonetheless, there is some overhead, and on extremely minimal wikis, versioning may not be absolutely necessary.

Related WikiMatrix fields:

See also