Combo is intended to be a ``community website in a box'' -- a set of CGI scripts, formatters, templates, and site-management tools that you can add to your web server to get a dynamic, interactive, web-based community up and running in no time. ``Combo'' doesn't really stand for anything; if you insist on an acronym you could try ``Combo Operates Member-Based Organizations''. It used to be called ``CWOK'', for ``Community Website Operating Kit''; we think Combo is an improvement.
Combo allows community members to upload ordinary HTML files and have them automatically formatted and themed to match the rest of the site, with keywords automatically cross-referenced to other pages. In addition there's a plain-text format, WikiWikiText, that is easy to edit in a web browser.
Combo is mostly written in Perl and runs on Apache, the world's most popular web server (for excellent reasons). It is designed to run efficiently on low-end hardware, including cast-off PC's and small server appliances like the Netwinder and Cobalt Qube, as long as you have enough bandwidth to support your community, and enough disk to hold your content. It should also make a good departmental intranet or family website.
The initial version is being developed by Steve Savitzky for use on the music co-op PenguinSong.net and its open-source software development site PenguinSong.org. In addition it's being used on the Linux review site Penguin-Lust.com, run by Steve's daughter Chaos and her friend Mayhem.
A Combo site has two general kinds of information: static and dynamic.
Static information can be maintained ``offsite'' under the control of the
site administrator's favorite version-control system. Dynamic information
is either uploaded to the site by users, created online by means of forms,
or generated by software (found in Combo's bin/ directory)
running on the server. It may also be under version control, but
in that case the version control will be running on the server.
After being uploaded, created, or edited, dynamic content is formatted: it is converted into HTML (or other suitable online format) if necessary, keywords are automatically crosslinked to other pages on the site, and index pages are updated. Plain HTML is usually massaged slightly to add standardized headers and footers and to permit automatic crosslinking. The processing is done by AMP, the Active Markup Processor.
The two file formats supported ``out of the box'' are extended HTML (in
.ht files) and WikiWikiText in .wt files. Since
PenguinSong is a music-based community, we will also be adding
abc, FilkTeX, and other music-related formats at some point.
Standard document markup languages like DocBook and LaTeX will be added
eventually.
It is also possible to use Combo completely offline to maintain a static website, giving the pages a uniform look and feel and generating indices and other navigation aids automatically. There will eventually be a special set of formats for marking up directories full of source code and, essentially, turning the CVS tree into a developers' community website. This is an extension of previous work on a system called WOAD, which is available from RiSource.org.
It's worth noting that, in almost all cases, dynamic content is expanded only once, at the time the source file is uploaded or edited. This greatly reduces the load on the server, at the cost of a little flexibility. If, for some baffling reason, you need a really dynamic site with user-selectable themes, browser-specific markup, up-to-the-moment content grabbed from other sites, or whatever, it's easy enough to set up some files -- or all of them -- to be expanded every time they're requested. But we don't recommend it.
Combo is designed to support several different classes of users, typically including the site administrators, community members, and the general public. In some cases it's useful to make a distinction between ordinary members and paying subscribers, and in many cases there might be a special group of contributors (for example, songwriters on PenguinSong.net, review writers on Penguin-Lust.com).
Community members and contributors each get what amounts to a website: a directory into which they can upload web pages, images, and so on. In many cases they -- or the community -- might want to allow comments (as on Slashdot.org or LinuxToday.com) or even a communally-written WikiWikiWeb.
Combo allows the ``owner'' of a page or a directory to specify which classes of users will have read, modify, or append, access to it.
Well, I had to write something to get PenguinSong.net up and running, but the main impetus for Combo came when my older daughter told me that she wanted to start a website where her friends could submit reviews and talk about Linux. At that point the little lightbulb went on and I realized that the two sites were really going to be pretty similar: both would need home pages for members and contributors, and both had contributed content (songs in one case, articles in the other). So here I am again, writing code when I ought to be out getting my exercise.
In particular, why not Python or Java? Well, Java runs like a snail on Valium on the kind of hardware I'm using; also there's quite a bit of text-hacking involved in this project, which Perl is ideal for. One of my previous projects (PIA) was prototyped in Perl and then rewritten in Java. Big mistake: it got bigger and slower.
Python is a lot cleaner than Perl and would be better for exposition -- I
understand it's a wonderful language for learning -- but I'm not at all
familiar with it and this is basically a rush job. Also, with Perl
there's always the option of using mod_perl, which I know to
be stable, fast, and reasonably secure. And most ISP's that support
websites with CGI's support Perl.
Why write another active-markup processor when PIA and cPIA are already available? Well, I could say that PIA was too slow, and that at the time I wrote it cPIA had a show-stopper bug I was too lazy to look for. I could say that I needed something GPL-compatible for a related project (SHAWM). But the main reason was simply to prove a point: that an Active Markup Processor is basically so simple that any competent programmer can write one in a couple of evenings. It wasn't exactly a weekend project, but in terms of the hours I put in it could have been.
Along the way, of course, I also came up with a processor that's simple
enough for mere mortals to understand and tinker with, integrates
seamlessly with mod_perl, and fits unobtrusively into
community-maintained websites disguised as a mild-mannered template
expander. It also works, mostly, on hosting services that provide only a
cgi_bin directory and no mod_perl.