Greetings,

This is a multi-purpose post.

Firstly promotional: test versions of a couple of extensions that I'm working on for http://clc-wiki.net have been installed on that site's test server: http://clc-test.flash-gordon.me.uk (content is an out-of-date mirror of the live site).

The extensions are: * A Treeview skin, described on the live site at: http://clc-wiki.net/wiki/Planning:Treeview_skin. This skin adds a new navigation support to MediaWiki, including a dynamic and configurable treeview and navigation bar, with load-on-demand for treeview nodes where browser-supported. * A voting extension, accessible at: http://clc-test.flash-gordon.me.uk/wiki/Special:Group_decisions. There's no general overview but there is/are: - a README in anticipation of future public release, at http://clc-test.flash-gordon.me.uk/mediawiki/extensions/Voting/README - hints on its motivations and direction at: http://clc-wiki.net/wiki/Clc:Roadmap - a (mostly current) description of the voting algorithm at: http://clc-wiki.net/wiki/Planning:Proposed_Charter#Proposal_And_Voting_Procedure (the charter as a whole proposal isn't current).

Comments on either extension welcome.

A few notes and caveats: * neither extension has been officially publicly released yet - the Treeview mainly because it hasn't been well tested and by nature its problems will vary by browser; the voting extension because it's too far from my long-term vision for it - this is more of a user-interface look-see. I'm also posting though to inform that these extensions exist so that duplicate effort can be avoided. * the content on clc-wiki is very much under development and incomplete. * the test server isn't running any form of code-caching such as MMTurck or eAccelerator so bear in mind that there's an avoidable setup penalty of about half a second per request (including for each on-demand load). It's running memcached with support enabled in MediaWiki though.

------------

Secondly some discussion on MediaWiki extensibility.

Statements from core developers to this list have been encouraging, and I'm able to write that neither extension requires patches against the 1.6 series core, although without patches client-caching has a few minor hitches for the treeview, and alert messages for the voting extension are not displayed.

I can write more on this and suggest some specific hooks and additions to core code that I think would round out these extensions, if any core developer is interested.

I'm also interested in restructuring Treeview so that rather than existing as a separate skin, it extends Monobook, but I haven't yet looked closely at how feasible this is using latest svn code - Treeview has until now been developed against 1.5.8, but there seem to have been a lot of structural changes to Monobook since then that might assist.

Also, I developed the colour preferences of the voting extension - http://clc-test.flash-gordon.me.uk/wiki/Special:Group_decisions/Prefs - with the idea that they might eventually be incorporated into the core, as part of a general framework for extensions to access user preferences. I gather from a comment that Brion Vibber made on the SoC proposals page that such a framework is in progress - I'd be interested in sharing ideas with the developer(s).

------------

Third, I'm encountering some MW + memcached problems on my development machine and before looking more closely wanted to run them by the list in case there's a quick answer like "that problem's expected with your set-up - do it differently".

I first noticed that intermittently the treeview's caching is failing - that the call to save its data structure to cache completes but on the next request the treeview is rebuilt again - a time-consuming operation - because the attempt to load it from cache comes up empty. The problem seems to be related to a message that has recently started showing up in the debug log (many times per request when it appears, but sometimes not at all) as: memcached: Error parsing memcached response I later enabled memcached logging by setting $wgMemc->_debug true but a cursory look at the new output didn't give me any more insight.

Some information that might be relevant:

* I run several versions of MediaWiki on the one machine sharing a database (including table prefix) and memcached server. No version in use is earlier than 1.5.8; the latest is a fairly up-to-date svn checkout. I haven't researched whether such a setup "should" work. I have noticed (tangentially related) that some cache keys don't seem to include $wgDBprefix as a component. * The problem persists after restarting memcached and limiting browsing to one of the MediaWiki instances. * I encounter (and have been encountering for a long time prior to this problem) other occasional problems with messages showing up in html output as ###NONEXISTENT### that it's not simple to remedy - the interactions between messages in language files, in the database and in the message cache is something I've not yet looked closely at, and it's complicated by my addition and modification of messages in(to) php files whilst developing. I'll have a closer look if there's no simple or quick explanation. * I recently installed eAccelerator on my development machine. Prior to its installation I hadn't noticed this problem. * Cache settings in LocalSettings.php for each instance are: $wgUseMemCached = true; $wgMainCacheType = CACHE_MEMCACHED; $wgMemCachedServers = array ( [identical server for each] ); $wgEnableParserCache = true;

------------

Finally a long-overdue update to a wikitech-l thread that I started in September last year, for anyone who remembers it and who follows this list too. The subject was "Differential storage"; it's archived at http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/19463.

In particular, to Tim Starling: I retrieved your test set - cheers - and wrote a few scripts that seemed to show qualified improvements, but I haven't worked on it further since then - nor written up any systematic results nor attempted to patch anything into MediaWiki.