[Mediawiki-l] New treeview skin + voting extension; extensibility; caching problem; differential storage thread update

[Netocrat]

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.

-- 
http://members.dodo.com.au/~netocrat