Comments by GregScott prompted me to start writing about my plans for Oddmuse, and about the way I plan to handle upgrades. There’s a Oddmuse:Plans page, too.

I’m not planning to blow the 4000 lines limit for Oddmuse. I am interested in new features, however. The 4000 lines limit for Oddmuse will just force me to think about them carefully, and to keep reworking the code to expunge all redundancy.

The line limit also makes sure that a single developer can understand all of it. In an emergency you can disable all the modules and it still “works”. That should make debugging much easier. In this case, modularity is not about code reuse but about debugging.

That’s why I don’t mind if the line count of the main script plus all the modules is close to 20’000. The important part is that the wiki itself is 4000 lines, and most modules modules are less than 400 lines each. It is possible to divide and conquer Oddmuse! 🙂

Upgrading Oddmuse may be more difficult than upgrading other pieces of software, because I don’t want to spend code on backwards-compatibility. Oddmuse is lean, and unfortunately for casual users, that means it is mean, too.

If a new thing requires a backwards-incompatible change, so be it. I will write scripts to deal with this, and I will write documentation for others performing the upgrade. I’ve recently started the Oddmuse:Upgrading Issues page for this purpose.

The major rewrite for 1.229 introduced a new file format. That format now uses the same format mail-headers (RFC 822) or RSS 3.0 uses. It is therefore much easier to handle for external programs than the old UseMod format. And yet it doesn’t require you to use an XML parser.

I feel like I’ve published hacks for config files first, then showed how to change the infrastructure using drop-in files (modules), but that all this time, hacking Oddmuse was the goal. I think we need to move to the next level and offer not tools but packages that implement a designed set of features. I’m thinking of a typical future family guy wanting to setup a wiki for his ten or twelve year old kid. He would copy Oddmuse, and drop three or four modules in a directory. That should be it.

If you ever want to rewrite a wiki engine, consider the MinimalWikiRequirements I collected.



I like wikis; they are easy to install, use and hack (three reasons for being easy).

All I read about Oddmuse here I think I like it, but this could become a potential barrier or turnoff for a user that reads “installing a module is easy: ...” in the “Don’t Make Me Think!” sense.

In other words, maintaining this procedure is ok ... but maybe also offer flavours of Oddmuse into pre-packed modules because there are many potential target populations.

Maybe this would better for the spread of this engine.

HTH – JuanmaMP 2007-07-18 18:57 UTC

This is something Alex was interested in doing for Oddmuse as early as 2004-04-01 Wikis, and fantasized about doing as a “consultant” in 2005-10-13 Software Web.

AaronHawley 2007-07-19 01:53 UTC

Wow, Aaron; many thanks for all the corrections (and links). :)

JuanmaMP 2007-07-19 03:01 UTC

My problem is that I can only provide this kind of setup for OSX, and people who have contributed Windows installers or Debian packages seem to have vanished after a few months... So 1. we don’t know how high the demand is, and 2. we don’t have any volunteers to do this.

AlexSchroeder 2007-07-19 14:02 UTC

Please make sure you contribute only your own work, or work licensed under the GNU Free Documentation License. Note: in order to facilitate peer review and fight vandalism, we will store your IP number for a number of days. See Privacy Policy for more information. See Info for text formatting rules. You can edit the comment page if you need to fix typos. You can subscribe to new comments by email without leaving a comment.

To save this page you must answer this question:

Please say HELLO.