--------------------------------------------------
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"
<wikitech-l(a)lists.wikimedia.org>
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
news:1006208056.1275619880.71836632.61224@mcgi66.rambler.ru...
> * Happy-melon <happy-melon(a)live.com> [Fri, 4 Jun 2010 00:33:30
+0100]:
>>
>>
>> One way to achieve this would be to develop the MediaWiki class to
>> actually
>> be what it originally promised: an object representing a wiki, of
> which
>> there can in principle be more than one instantiated at any one
time.
>> Configuration options could determine
how the MediaWiki object
> accesses
>> data, and consequently what sub-entities it is able to produce.
>>
> Current MediaWiki class has some shortcomings. For example, when
I've
> tried to setup rendering urls in my very own
way and not using
> mod_rewrite, I've "cloned" and "refactored" index.php. The
problem
was
> 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
different
> from default $wgOut. And $wgArticle, too. The engine didn't work as
> expected, it still was looking for the default names here and there.
I
> was forced to use default wgOut and
wgArticle names. But, then,
there
is
> no real incapsulation and there is no point to pass these as method
> parameters..
>
> I'd imagine that "emulated" request or api through the local farm
can
be
done really fast, while real remote interwiki
call would be done in
usual way (api).
Dmitriy
Indeed; it does need a lot of work; doing it properly would probably
deprecate all the state globals ($wg(Title|Parser|Article|Out|Request)
etc);
replacing them with member variables of the MediaWiki class. How
other
classes would access those variables is an
interesting question; I
could
see
an Article::getWiki()->getOut() chain, but that won't work for static
functions. It would be a major overhaul, but would probably kill
several
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
errors).
Dmitriy
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.
--HM