Thread:Talk:Requests for comment/New sites system/First-class data or index/reply (4)

I just mean that if I go with making the web UI use a revision system like we do for edits instead of modifying the site table directly and everyone starts using that for actual editing of the sites list then we'll basically just have a web ui using sites as an index and a sync system using sites as an index and pretty quickly almost no-one will be using site as a first-class table.

This was just a note to provide the background to the rationale why we might want source instead of a boolean. It's combined with the above.

The line of thought behind a source string instead of primary/non-editable (what is an editable index?) is this:
 * The web UI manages it's data with a revision system and it indexes the site table off that so it says the site table is an index
 * Wikidata/MediaWiki sync site data from a foreign source so it says the site table is an index
 * In both situations the site table is set as an index. How does the web UI tell the difference and know if it is allowed to update the site table with it's locally edited revision data?

Hmmm... I didn't think about that before.

I know talked about things like having a text and page based interwiki source. But those are actually only things that come to mind when I think about what we'd do to make this easy for users too use soon. Honestly what I really want is one really good web UI. Once that is done and we're using this global id based system with local prefixes I actually don't really see any use for any other user interface anymore.

I do believe that if I put global data about sites inside of revisions in a web UI I'm probably going to do the same thing with local data. So whether we want site_source or two columns for this will depend on if you believe we're going to have multiple editing interfaces on one single wiki disagreeing on where the local data comes from. The idea of site_source came up because global data can come from anywhere (direct local db edit, wiki UI edit, synced from wikidata, synced from another database, synced from a wiki's API) which at the start I didn't think applied to local data that always came from somewhere on the same wiki.