User talk:Peter17/Reasonably efficient interwiki transclusion

Hi Peter, I'm not so deep into wiki software, so ignore my comments if fool.
 * 1) When you mention templates, I presume, you'll address to any wiki page, since any wiki page can be seen as a template, and works as a template.
 * 2) Please consider deeply and carefully the software and the philosopy of Extension:Labeled Section Transclusion. It's an extension mainly used into wikisource projects, but it would be extremely useful to any wiki project for very sound reasons, I only wait that it is discovered.... it is simply unknown. Just an example: I usually write multi-axial arrays into a single wiki page with a very simple code... sometimes with hundreds, or thousands of elements. I'd like to post here an example of its features, but I can't since the extension isn't installed here.... ;-) --Alex brollo 09:27, 25 May 2010 (UTC)


 * Hi Alex,
 * # Yes, I noticed that my text was somehow unclear... The aim is to be able to transclude any page. I will correct that.
 * # I have read that page, but I didn't know this extension before. Transcluding sections by heading (like #lsth) would be great for my project. I don't know if I can use the API for that but I will check. I don't know if #lst or #lstx are in the field of my project, but I will keep it in mind! I don't really understand what you want to to with multi-axial arrays... Do you have an example on another wiki?
 * Best wishes. Peter17 09:49, 25 May 2010 (UTC)

What about a more comprehensive approach, allowing a unified page table, and certain pages therein, to be shared across two or more wikis
Hi Peter, I am working on an extension to fix a number of bugs that are within the purview of Project:WikiProject Interwiki Integration. I have proposed that we add a field to the page table that could be set to one of three values: (1) The wildcard "*" for all wikis; (2) The name/index of the one wiki/database to which the page pertains; or (3) A foreign key leading to a table with wikis/databases as its fields and boolean values as its contents. There would be a function, e.g. Title::getDatabases, that would access that table and return an array of all the wikis/databases that a page pertains to. (This need not be set up as just one field in the page table; in fact, it might be better to set up as 2 or 3 fields.)

The idea is that wikis on a wiki farm could use $wgSharedTables to share the page table, and then the wikis could have "global" or multi-wiki pages that the software would recognize as being present and identical on all the wikis in that array. Thus, an edit to the page on one wiki would change it for all the wikis that page is shared on. I suppose pages could also be set up as having a "home wiki" that would be the only wiki the page could be edited from (creating something functionally equivalent to mere interwiki transclusion), or restrictions could be set up on a per-wiki basis. Maybe users blocked from editing on the page's "home wiki" would be unable to edit the article, but otherwise users could edit it from any wiki that the page is shared on. There are a lot of possibilities.

Probably setting up a page to be shared could be done in a similar manner as moving an article; that is, the page would have to be non-existent on the local wiki, or the only item in the page history would have to be a redirect; otherwise, admin assistance would be required. Tisane 14:16, 1 June 2010 (UTC)


 * You can't share the page table; it would break database integrity everywhere unless you also share revision (and hence text), templatelinks, pagelinks, recentchanges, page_props, basically the entire database. Then you have your entire wiki farm running off one database, which doesn't scale: WMF's wikis are split into six clusters for precisely the reason that one database can't handle the load.  Happy ‑ melon 18:37, 1 June 2010 (UTC)
 * Also, this project is specifically about interwiki transclusion, which is difficult in and of itself. That alone is a reason not to do this; Happy-melon's arguments for why this is a bad idea are also right on the money. --Catrope 19:50, 1 June 2010 (UTC)
 * @Happy Melon: I pretty much do think that the whole database should be shared, much as different namespaces share the same tables. Or rather, I think they should be shared if a way can be found to do it without causing the scaling problems you mention. An alternative is to set up global page tables kinda like the global user tables that CentralAuth sets up; that would probably be the superior method if an extension is going to be used. @Catrope: I'm not trying to steal anyone's thunder or step on anyone's toes if you guys just want to do interwiki transclusion, so I'll leave off further commentary on my proposal here. Tisane 21:45, 1 June 2010 (UTC)
 * @Tisane: Hi! Your approach seems interesting. I think it could replace interwiki transclusion (inside WMF's farm), as the requested foreign pages would not be distant anymore. As Catrope said, it is a little different from my project, but that could be a more comprehensive way of implementing it. However, Happy-melon's remarks are to be taken into account and my knowledge of the system is not complete enough to answer on this point. I think it should be discussed on wikitech-l before, so, we can get ideas from more people.
 * Another goal of my project is transclusion to foreign wikis, so, the two projects are actually different even if they have a common part. Peter17 00:17, 2 June 2010 (UTC)
 * As the saying goes, There's more than one way to do it. As you've pointed out, local caching of transcluded foreign pages could help mitigate server load. I've done a bit of work on foreign interwiki integration, specifically Extension:RPED, which maintains a table of data on foreign wiki page titles. There is also a bot to read the IRC recent changes feed and update the table as page creations/deletions/moves occur on the foreign wiki. Perhaps your local wiki could maintain a cache of transcluded pages on the foreign wiki, and whenever an edit to one of those pages appears on the IRC feed, it could grab the latest version of that page via the API. Maybe the bot could run on a centralized server and push the data to each of its client wikis, so that there wouldn't have to be a bunch of local wikis running the bots and making redundant API requests. Tisane 00:48, 2 June 2010 (UTC)

Core or extension?
Is this functionality envisaged as being implemented as part of the core or as an extension? If the latter, I would think that rather than adding fields to the interwiki table, one would want to put them in a new table, to be added by $wgExtNewTables, unless it is planned that the field will find other uses as well (which is probably the case). Then again, there are the performance issues mentioned at Extension talk:InterwikiIntegration that occur when one reads from the database rather than from variables set in, e.g., InitialiseSettings.php. It's a subject I've been mulling over a lot lately.

Are you envisaging that the interwiki table will be shared among the wikis on a wiki farm? I figure that way, if a change needs to be made (e.g. a new wiki is added), one SQL query can change it for all the wikis. Tisane 00:04, 15 June 2010 (UTC)


 * Hello, Tisane. Sorry for this late answer. I am currently programming the functionality in the core. This aspect (core or extension) has not been discussed yet, but as my code will replace "scary transclusions", which is in the core, I assume that I have to program this in the core. When discussing on the list and with my mentor, it has never been mentioned that it would be an extension...
 * About the other implications of my change, I just know that adding the URL of api.php in the interwiki table has already been discussed and will be useful for other purposes (I don't know which ones yet).
 * About sharing the interwiki table, I really have no idea. This table already exists and I don't need it to be shared. Sharing it should be discussed more globally... Peter17 16:00, 16 June 2010 (UTC)