On 05/25/2010 01:41 PM, Peter17 wrote:
2010/5/25 church.of.emacs.ml
<church.of.emacs.ml(a)googlemail.com>om>:
2. Parsing the wikitext at the home wiki makes it more difficult to use
site magic words, e.g. {{CONTENTLANGUAGE}}. You'd have to pass one each
and everyone as a template parameter (e.g.
{{homewiki::templatename|lang={{CONTENTLANGUAGE}}}})
Ok, I will keep this in mind. Parsing the template on the home wiki
seems necessary because it can use other templates hosted on that wiki
to render correctly... I think it is the most logical way to do, isn't
it?
Yes. When I think about this a bit more, it makes sense to parse on the
home wiki, because otherwise (a) you couldn't include other remote
templates or (b) you would need one API call per included template. Both
not feasible.
However, you'd have to worry that each distant wiki uses only a fair
amount of the home wiki server's resources. E.g. set a limit of
inclusions (that limit would have to be on the home-wiki-server-side)
and disallow infinite loops (they're always fun).
What do you propose for linking? If a template on the home wiki links to
[[Foobar]], should that be an interwiki link to [[homewiki:Foobar]], or
a local link in the distant wiki? In any case, there should be a way of
differentiating home-wiki and distant-wiki references (links, inclusions).
On 05/25/2010 02:25 PM, Chad wrote:
That's not scalable on Wikimedia sites. Making
external HTTP
requests to other wiki's APIs just isn't fast enough; you must
use the database for remote wiki information in the WMF. I
suggest taking a deeper look at how the FileRepo does things.
The abstract class FileRepo handles the high-level stuff while
LocalFile, ForeignDBRepo and ForeignAPIRepo handle the
specific implementations for things like getting thumbnails or
metadata.
Do I understand this correctly... you can either access a foreign
repository via the API (if you're on another server) or directly via the
database (if you're on the same wiki farm)? Very cool stuff.
Regards,
Church of emacs