All the Perl that's Practical to Extract and Report

Backwards (in)compatibility

Kake on 2003-01-05T23:54:07

I should have known this was going to bite me in the arse at some point. I needed to add another table to the database schema for CGI::Wiki, to store details of which nodes link to other nodes, so we can do backlinks properly (ie, find out all nodes which link to a given node).

This means anyone upgrading from a pre-0.15 version needs to re-run the setup script on their database, so they have the extra table. If they don't, then their code will complain and die when they try to run it on an existing database.

Unfortunately the setup scripts distributed with pre-0.15 versions of CGI::Wiki have the nasty side-effect of deleting all your data if run on a pre-existing database. This is fixed in 0.15, but it means you really have to be sure which versions of the modules you're running the scripts with, if you're trying to fix up your existing database to work with the latest CGI::Wiki.

This is documented in README, INSTALL, Changes and the pod of Wiki.pm — I hope that's going to save anyone from getting annoyed with me.

On the bright side, we do get real backlinks, which is very cool (blair christensen's idea so thank him if you like it).

This links in to something I've been worrying about for a while — how do you pick the right balance between:

  • releasing early enough that people can use what you're doing, avoid reinventing wheels, and give you good ideas
  • not releasing so early that you have an absolute nightmare trying to keep backwards compatibility when you add new features that you didn't have time to get in before your first public release

The first release of CGI::Wiki took two months to escape from when I first thought of it, and I purposely delayed it until I'd decided how I was going to put version information in the tables. I hadn't even thought of backlinks at that point; it was only after I released it and blair mailed me that I realised they'd be useful. So even if I had delayed it longer, I'd still have the backwards compatibility problem now.

I'm actually less worried about changing the database schema than I am about changing the interface. At some point soon I'm going to start adding the capability to store metadata about the nodes, and right now I'm really feeling that the nodes should have been objects. Which one's neater:

$node = $wiki->retrieve_node("Penderel's Oak");
$node->add_metadata( type => "Categories", data => "Holborn" );
$node->write;

or

%node_data = $wiki->retrieve_node("Penderel's Oak");
$wiki->write_node("Penderel's Oak", $node_data{content}, $node_data{checksum}, { type => "Categories", data => "Holborn");

Now guess which one I've saddled myself with.

However, reasons to be cheerful:
  • Lots of Wiki-related stuff has been happening on CPAN recently; Apache::MiniWiki 0.7, AxKit::XSP::Wiki 0.05 and Text::WikiFormat 0.5 have all been uploaded in the past week. Wikis must be sexy again, or something.
  • I've got a reasonable emulation of a usemod wiki running under CGI::Wiki — it copes with much of the usemod formatting style, plus it does things like redirects and backlinks-via-title-link (except it does them properly instead of just by searching on the page title).
  • chromatic was lovely and applied my patches to Text::WikiFormat just like he promised. Then I got all excited and sent him new ones :)
Current to-do list:
  • Get phrase searching working with Search::InvertedIndex
  • Look at the code Roger sent me ages ago (sorry Roger, I'm slack)
  • Release CGI::Wiki::Formatter::Usemod
  • Think about that damned metadata problem
  • Write CGI::Wiki::Formatter::Pod
  • Get my head round Jo's RDF/grubstreet ideas
  • (very speculative) Think more on the recipe DTD/semantic web stuff I was talking about with Earle

Sexy!

Matts on 2003-01-06T11:50:37

Yes, I think wiki's are pretty sexy. The reason I've got completely separate Wiki modules is that Text::WikiFormat is slightly designed to allow overriding the output, but it doesn't go far enough. It's still very much designed to take Wiki text as a string and output a string. If on the other hand you adopted the SAX model, your input can be a string, a file or a filehandle, and the output is a data format (which you can then turn into a string or HTML if you so wish). I need that flexibility to be able to properly process Wiki text as XML in the AxKit Wiki.

The other thing about the AxKit wiki is that you can author pages in POD, which I find very sexy indeed. POD isn't the world's best format, but it's actually really well suited to Wikis.

(I concur with the database update issue - it's a complex problem that I've never seen solved perfectly).

Re:Sexy!

Kake on 2003-01-07T00:34:13

Matts wrote:

The other thing about the AxKit wiki is that you can author pages in POD, which I find very sexy indeed. POD isn't the world's best format, but it's actually really well suited to Wikis.

Now look what you made me do.

I must look into AxKit at some point. I seem to have the idea that it'll all be too complicated for me to grasp, though this may or may not have any relation to reality.