The Jackal Rants

While quite flexible, our existing parser hook mechanism is a bit limited for developers wanting to affect the OutputPage object representing the actual rendered page; things like adding links to stylesheets or attaching JavaScript aren’t easy to do, mainly due to caching.

I’ve been messing about in a branch, preparing a mergeable version of a not-too-ancient patch Brion put together which adds a neat mechanism for working around this; extension output handlers.

An extension output handler is basically an object which is attached to the ParserOutput, and so is serialised and stored in the parser cache along with everything else (page text, metadata, etc.). The idea I had for implementation, prior to inspecting Brion’s code and deciding it was a better solution, was to provide a couple of simple accessors and mutators in ParserOutput and use these, combined with hooks executed when the page is put together, to make the changes.

However, the output handler mechanism is a lot nicer, especially from the developer’s perspective, since it takes a lot of the hook hassle away. By avoiding the hook mechanism, it’s probably more efficient, although I don’t pretend to have any benchmarks to back up that guess at all.

The great news is I barely had to write any code at all…Brion’s patch was easily adaptable to the branch, and all I really did was write my own little test extension to make sure it actually worked…and it does, well. I’ve written up (hopefully) thorough documentation and put a prettified copy of it on the MediaWiki.org web site.

Now I’m waiting for the aforementioned to review and approve it for merging. Once this, or something offering the same capabilities, goes live, then we have much greater flexibility in the quality of parser hook extensions we can write, and for my mind, I’ve got my eye on the idea of a nice little slideshow extension…

I’ve been hacking up query pages so that results are formatted into galleries when the report deals with images; things like uncategorised images, unused files, etc.

All well and good, but it reminded me just how old the query page mechanism is in the general lifecycle of portions of our code, and it reminded me how crappy some of it was, with no direct offence intended to whoever actually wrote it.
Unfortunately, quick-fix code usually attracts nastier hacks on top, and as we all know, this makes for horrible, unmaintainable code. This is often a norm with the MediaWiki codebase, although some modules seem to get rewritten often enough to keep a clear cycle of efficient, clean, comprehensive code in place.

There are several portions of the code base which we probably need to gut; the image storage backend is long overdue an overhaul, but that’s a major project, and major projects sap up review time. Time which we don’t really have.

Well, it looks like I won’t be participating in Google Summer of Code 2007, which is a bit of a shame, but there it is.

I haven’t had the time this week to decide upon a project, and although Google have extended the deadline for applications to the 26th, I won’t have time now to take the ideas put forward so far and prepare a decent proposal for consideration.

Furthermore, I’m somewhat disinclined to participate in heavy development at the moment owing to the machinations of the development team – there’s quite a lot of hassle coming from certain new committers, and the recent attitude coming off some sponsored developers makes me not want to join their ranks.

It’s the time of year, now that spring is in the air, for those two wet gits…er, I mean, it’s time for Google Summer of Code again. If I’m going to take part this year, then I need to decide what I’m going to do and submit an application by the end of next Friday.

My schedule at the moment may very well make that impossible…