-------------------------------------------------- From: "Dmitriy Sintsov" <[email protected]> Sent: Friday, June 04, 2010 11:01 AM To: "Happy-melon" <[email protected]>; "Wikimedia developers" <[email protected]> Subject: Re: [Wikitech-l] Reasonably efficient interwiki transclusion
> * Happy-melon <[email protected]> [Fri, 4 Jun 2010 10:03:14 +0100]: >> >> "Dmitriy Sintsov" <[email protected]> wrote in message >> news:[email protected]... >> > * Happy-melon <[email protected]> [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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
