Dmitriy Sintsov wrote:
- Roan Kattouw roan.kattouw@gmail.com [Tue, 25 May 2010 20:58:54
+0200]:
2010/5/25 Aryeh Gregor Simetrical+wikilist@gmail.com:
Having Wikimedia servers send HTTP requests to each other instead of just doing database queries does not sound like a great idea to me. You're hitting several extra servers for no reason, including extra requests to an application server. On top of that, you're caching stuff in the database which is already *in* the database! FileRepo does this the Right Way, and you should definitely look at how that works. It uses polymorphism to use the database if possible, else
the
API.
However, someone like Tim Starling should be consulted for a definitive performance assessment; don't rely on my word alone.
This is true if, indeed, all parsing is done on the distant wiki. However, if parsing is done on the home wiki, you're not simply requesting data that's ready-baked in the DB and API calls make sense. I'm also not convinced this would be a huge performance problem because it'd only be done on parse (thanks to parser cache), but like you I trust Tim's verdict more than mine. Unlike Platonides suggested, you cannot use FauxRequest to do cross-wiki API requests.
To the point of whether parsing on the on the distant wiki makes more sense: I guess there are points to be made both ways. I originally subscribed to the idea of parsing on the home wiki so expanding the same template with the same arguments would always result in the same (preprocessed) wikitext, but I do see how parsing on the local wiki would help for stuff like {{SITENAME}} and {{CONTENTLANG}}.
Having a something like FarmRequest or FarmApi classes would be a great think for wiki farms (I run a small one). Probably also would help to unificate the remote vs local farm code. Though, a Farm probably should become an object containing wiki configurations. Currently farms are a bit "hackish". Dmitriy
^_^ "hackish" isn't that bad in some sense. I'm currently experimenting with some farm code that works completely outside of MediaWiki rather than as a extension sitting inside of it. Using a sandbox it can get access to the MediaWiki install and extract info from it in a secure way which couldn't be extracted as easily from the api. The system works more like a MediaWiki virtual machine than a MediaWiki installation turned WikiFarm. The result is a farm free of mapping issues which can give MediaWiki hostees much more control over the installation then they could on a normal WikiFarm, including the ability for different wiki on the wiki farm to run completely different versions of MediaWiki and upgrade independently, and have control over their own list of installed extensions. ;) In fact this works using complete raw unmodified MediaWiki source code. I have a few "source" directories with MediaWiki source, they don't have any changes to them, and then end up being run in the VM thinking they are a complete installation modified with all the stuff they need to run. ^_^ Tricking MediaWiki into thinking it's a single installation sitting on it's own from the outside is definitely "hackish". In any case, Farm{Request,Api} is a nice and interesting idea.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]