On Wed, Jun 16, 2010 at 12:07 AM, Tisane <[email protected]> wrote: > It seems to me that if we want to modify the core to support interwiki > integration, there are any number of core tables that could benefit from DB > name fields. E.g., user_newtalk could have a DB name field, so that users > could be informed which wiki(s) they have new messages on.
Why? Their home wiki is already stored in CentralAuth, as well as all wikis they're already a member of. A db name column in user_newtalk would be pretty useless. > Do we ultimately > want to implement such capabilities in the core, though, or through > extensions? Presumably some tables will be harder to share than others, so > in the harder cases it will make more sense to have global tables, kinda > like what CentralAuth sets up, unless we want to do a major revamping of the > code. > Absolutely it should be in core. Right now, each time an extension (or core) author wants to do something with an interwiki site, they usually reinvent the wheel every time. Having a centralized (CORE!) methodology of obtaining a remote DB connection or API request for interwikis would be a huge step in the right direction. As Domas points out, WMF doesn't use the interwiki table. Data like API urls and DB connection info should be extended to the IW cache, so users of that can make use of this data as well. On Wed, Jun 16, 2010 at 4:33 AM, Domas Mituzas <[email protected]> wrote: > 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.. :) You're right. But centralizing this sort of thing makes long term planning for that sort of thing easier. And by putting it in core you get more eyes on it and hopefully more people caring :) -Chad _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
