-------------------------------------------------- From: "Dmitriy Sintsov" questpc@rambler.ru Sent: Friday, June 04, 2010 11:01 AM To: "Happy-melon" happy-melon@live.com; "Wikimedia developers" wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Reasonably efficient interwiki transclusion
- Happy-melon happy-melon@live.com [Fri, 4 Jun 2010 10:03:14 +0100]:
"Dmitriy Sintsov" questpc@rambler.ru wrote in message news:1006208056.1275619880.71836632.61224@mcgi66.rambler.ru...
- Happy-melon happy-melon@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