On Wed, Jun 16, 2010 at 4:33 AM, Domas Mituzas <midom.li...@gmail.com>wrote:
> I personally don't like the "interwiki integration", as pretty much > nearly everything has to go through one of these methods: > > 1. Pulling from all wikis > 2. Pushing to all wikis > 3. Having central backend > > All these have their own nightmares, and separation was quite often > preventing us from madness. CentralAuth has added its own share of > inefficiencies that nobody has been working on yet. Having shared data > between multiple systems isn't the easiest problem usually, and it > needs more attention than a single-time feature deployment. > I'm hoping that CentralAuth can either be made easier for non-WMF wiki owners to install/configure/use, or that another, less-WMF-specific, and easier-to-work-with extension (or core functionality!) can be developed to fulfill the functions it performs, and more. Do you have any thoughts on which of those three options above are preferable to use in which situations? I'm presently working on Special:InterwikiWatchlist and Special:InterwikiRecentChanges pages that use shared global integration_page, integration_recentchanges, integration_watchlist, etc. tables. These are just like the existing page, recentchanges, watchlist, etc. tables, but they also have a global primary key and a field for a database identifier. Each wiki is responsible for pushing data to those global tables via hook functions whenever pages are created, edited, watched, deleted, etc. > I have no idea what major revamping you have in mind, when it comes to > data sharing. > > Do note that we don't have any data consistency framework for > cross-database publishing, so you will always end up with > inconsistencies around, that are not guarded by transactions. For each > feature that means building a conflict/consistency management.. :) > There seem to be three major paths. (1) Let each wiki query all the others when it needs interwiki data such as recent changes, (2) share tables, or (3) share global tables. I think option #1 leads to constantly needing to use foreach statements to go through all the wikis, or else doing massive JOINs. I'm not sure what the pros and cons of option #1 are, as far as efficiency is concerned. Option #2 works OK for stuff like the user table, put people have told me that it's hopeless trying to share tables like the page table. My original idea had been to add a global primary key and a database identifier to the page table and then share it, but when the idea was roundly panned, I ended up instead going with option #3 by sharing a new global integration_page table that looks basically like what the shared page table would have looked like. The only difference is, it's changed through hook functions rather than though functions in Article.php. -Tisane _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
