On Wed, Jun 16, 2010 at 12:07 AM, Tisane <tisane2718(a)gmail.com> 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 <midom.lists(a)gmail.com> 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