For backwards compatibility the Interwiki::load interface to listing interwiki links may be retained as a primary interface for fetching an interwiki.
The interwiki system should work in a file repository like way:
Multiple repository types like database (the current way), flat files (csv, json, tabulated, etc...), flat files over http.
Each repository will need a ->list( ... ); function, the overall static interface will need a list that will list over the listing interfaces in each instance. This will replace the use of $db->select to list interwiki items.
Tip: Theoretically if you sort prefixes in each ->list it is possible to do an overall list that does not require (did we do this one before) checks on a long list when dealing with fallback interwiki sources. As you can do greater than or less than checks while listing.
Instead of pre-loading interwiki links into the database in new installations we can just maintain a standard built in csv file as a fallback (which we can actually update).
<p858snake|l> do we even need half those entries in the default interwiki list >.>
<Dantman> p858snake|l, agreed..... we should also make it easier to modify, and share bundles of lists...
<Dantman> Actually... I'd argue we might not necessarily even want the db as our only list
<Dantman> I just created a new wiki recently... and it's somewhat related to two other wiki I made in the past...
<Dantman> they
<Dantman> they don't necessarily share the same interwiki db, but it would've made much more sense to have one shared batch of iw mapping of a name for each wiki mapped to the url...
<Dantman> So that when I add a new wiki, each wiki shares the new interwiki and the new wiki gets the links automatically
<Dantman> db format, flat files, csv, json, tabulated, etc... something that supported multiple inputs like our file repos
<Dantman> We could stop importing that db for new wiki, and just fallback to a default csv
<Dantman> ((which we can actually update with the software)) ;)
<Dantman> file formats over http too
