Requests for comment/New sites system

Our interwiki system is dated. There are a number of issues with it that need to be fixed by replacing it with a new system.

Issues that need to be solved in a new system:
 * Global IDs: Right now the ID for an interwiki link is local to the wiki. Even when wikis share data there is no global id for interwiki links. The new system should have a global id field which will be unique and the same across all wikis sharing the same data. (Wikidata needs this)
 * Multiple IDs: For any individual wiki one interwiki/site may be referred to by multiple interwiki links. In the current interwiki system to do this you have to create duplicate rows. In the new interwiki system duplication should be avoided by using a list (likely a separate table) of multiple local prefixes for one site row.
 * Types and Typed data: Our interwiki system currently refers to more than just MediaWiki sites but treats them with MediaWiki url handling. This leads to some links like google: being broken. While also making other things underpowered. The new system should understand different types of sites so we can give different types of sites different link handling. It should also have type specific data where we can relocate the api location and put some other information inside.
 * Languages: Our current interwiki table only understands languages for interwiki links that are interlanguage links using a language code as a prefix. The new sites system should annotate all websites with information about what language the site is in.
 * Arbitrary interlanguage links: Our current interlanguage system only supports interlanguage links that are the same as a language code. The new sites system should instead make this an explicit flag so that some prefixes that don't match known language codes can be used as interlanguage links.
 * [Note] Where should we put this data? The obvious idea would be to put it on the sites table itself. But thinking about it Wikipedia: would be a normal interwiki while en: would be an interlanguage link. Perhaps we should put that boolean on the table that lists prefixes and tie it to a prefix. Special page UIs can just have two separate inputs for interwiki prefixes and interlanguage prefixes to make a sane input method.
 * [Note] Wikidata's proposed sites table called this site_link_navigation. And a boolean true would make a link go into the navigation / langlinks instead of act as an interwiki. However perhaps this isn't something we only want for interlanguage links. Maybe we want sister sites too? We may want to make this varbinary instead of a boolean and support the possibility of another type of navigation link.
 * [Note] We may also want to think about how this fits into the context of the idea of putting all interlanguage links into a central database.
 * Groups: Wikidata's sites table suggested that we should have a column to group sites together. eg: All Wikipedias are in one group.
 * Custom URLs: The API of the sites system should take into account the possibility of types that introduce very custom url patterns.
 * [Example] If we want to create a Gerrit type we will probably want  to link to https://gerrit.wikimedia.org/r/18094 while   would link to https://gerrit.wikimedia.org/r/#q,Idd03d309cc3b71728a8cbea460efa12b10348d64,n,z in other words a completely custom url type that does not fit into a $1 site_url pattern.
 * Unprefixed sites: The new sites system should permit the creation of sites that don't have any local interwiki or interlanguage prefix.
 * [Use case] This could help synchronization by letting every wiki just copy everything instead of only what it has prefixes for.
 * [Use case] Wikidata will need this in some form for external language links that don't have a local prefix.
 * [Use case] Besides wikidata this could also be useful if we try replacing interlanguage links with something that doesn't use prefixes. Like in.
 * [Use case] This could also be useful if someone ever comes up with a UI that needs to let you pick sites from a list to make a link for some purpose.
 * [Note] Wikidata's proposed sites table tries to deal with languagelinks by always having a site_local_id even if it is not an interwiki. To do this right we should probably do something else such as replacing ll_lang with a column pointing to a site_id. This needs some more thought and discussion.
 * Or maybe — taking interproject discussions into account — we might want to drop languagelinks and open up a new table that lets us have more than just language links. Daniel Friesen (Dantman) (talk) 07:34, 14 August 2012 (UTC)
 * Synchronization: large projects like Wikimedia have many wikis and the idea of re-doing the interwiki table for every single wiki is ridiculous. Wikis in a large project will need some way to share or synchronize their list of sites with each other.
 * [Note] Sites have data that is global and also data specific to the individual wiki. Do we want to split the data into two different tables?
 * [???] Do we want to include a site title into this information? There is a possibility some of our new use cases may have a use for such a thing. We also never discussed whether interwiki links should actually use titles like "Foo - Wikipedia" instead of "Wikipedia:Foo".
 * [Existing] Our MediaWiki type needs to know how to access the API of another wiki. Our current interwiki table uses a iw_api column for this. The new one will probably use special site data (like a scriptpath instead of a api url) to get the same information. Though it may use type specific data for that.
 * [Existing] Our MediaWiki type needs to know about wikiids that can be used to access the database of another wiki. ie: With . The current interwiki table has a iw_wikiid column for this. The new system will probably use type specific data for this.
 * [Existing] We need an equivalent to iw_local which indicates that when the title is an interwiki link it should support redirection. This should probably apply to all types and be a general part of the site row.
 * [Existing] We need an equivalent to iw_trans that indicates scary transclusion should work. This will probably be type specific data. And in a data key that we don't even bother setting if it's not enabled for that wiki.
 * [Bonus, UI] We have no standard UI to make this editable. That means for most people this is a black box they can never touch. We need a new special page for editing sites after we write the new system.
 * [Idea] We nave no versioning of this data so we're entirely dependent on half-baked logs for changes. We may want to consider treating sites as an index so that a UI can edit versioned information instead of the sites table and then build the index from that data.
 * [Idea] Detection: We expose the location of the API with an EditURI pointing to a RSD file in supported versions of MediaWiki, and in siteinfo we expose all the information we need to know to link to that wiki. The UI should probably take advantage of that and let people register MediaWiki urls simply by sticking a single link into them that the special page uses detection on to extract all the info it needs.

Database schema
[...TBD...]

External API
[...TBD...]