* Roan Kattouw <roan.kattouw(a)gmail.com> [Tue, 25
May 2010 20:58:54
+0200]:
2010/5/25 Aryeh Gregor
<Simetrical+wikilist(a)gmail.com>om>:
> 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) [