From: "Dmitriy Sintsov" <questpc(a)rambler.ru>
Sent: Friday, June 04, 2010 11:01 AM
To: "Happy-melon" <happy-melon(a)live.com>om>; "Wikimedia developers"
Subject: Re: [Wikitech-l] Reasonably efficient interwiki transclusion
* Happy-melon <happy-melon(a)live.com> [Fri, 4 Jun
2010 10:03:14 +0100]:
"Dmitriy Sintsov" <questpc(a)rambler.ru> wrote in message
> * Happy-melon <happy-melon(a)live.com> [Fri, 4 Jun 2010 00:33:30
>> One way to achieve this would be to develop the MediaWiki class to
>> be what it originally promised: an object representing a wiki, of
>> there can in principle be more than one instantiated at any one
>> Configuration options could determine
how the MediaWiki object
>> data, and consequently what sub-entities it is able to produce.
> Current MediaWiki class has some shortcomings. For example, when
> tried to setup rendering urls in my very own
way and not using
> mod_rewrite, I've "cloned" and "refactored" index.php. The
> with the following call:
> # warning: although instances of OutputPage and others are passed,
> # they are sometimes used as "fixed" wg* globals in other classes
> # so you cannot pass a non-global here, or use the different names
> # of passed instances
> $MW->initialize( $wgTitle, $wgArticle, $wgOut, $wgUser, $wgRequest
First, I've made an instance of OutputPage with variable name
> from default $wgOut. And $wgArticle, too. The engine didn't work as
> expected, it still was looking for the default names here and there.
> was forced to use default wgOut and
wgArticle names. But, then,
> no real incapsulation and there is no point to pass these as method
> I'd imagine that "emulated" request or api through the local farm
done really fast, while real remote interwiki
call would be done in
usual way (api).
Indeed; it does need a lot of work; doing it properly would probably
deprecate all the state globals ($wg(Title|Parser|Article|Out|Request)
replacing them with member variables of the MediaWiki class. How
classes would access those variables is an
interesting question; I
an Article::getWiki()->getOut() chain, but that won't work for static
functions. It would be a major overhaul, but would probably kill
birds with one stone.
Hundreds of extensions would break :-( Compatibility is a huge burden. A
crude but simpler approach would be having these globals saved in some
context data structure and introduce Farm->switch() method, which would
save/replace all the globals. Much less of core has to be changed, then.
However, that's a bit more unreliable and risky. However, the code is
fragile, anyway (from my exp, one typo sometimes can cause dreaded
MW 2.0? :-D
You wouldn't need to remove the globals, at least immediately; you'd retain
them as aliases for the relevant variables of the 'main' wiki; assuming that
it makes sense to define one primary wiki, which it usually does.