Yesterday, Erik Moeller mentioned that it might be best to hold off with
the wikidata development, and instead do that in a "quantum leap"
MediaWiki 2.0 version.
Which got me thinking: Should we start this (at least, plan it)?
There are quite some concepts and ideas that were proposed, but seem to
be hard to do with the current line of development. Examples:
* WikiData
* cur/old integration
* stable revision number for both cur/old
* single login
* XML parser
* use of wikicommons
* centralized interwiki link management
* stable/editable version management
* SVG support (editable SVG source?)
These are just the ones I come up with in a minute. There are, no doubt,
more.
Sure, some of them *can* be integrated into 1.3/1.4, but considering the
sum of the above, it might call for some radical break.
Which leads to the question: Fork or rewrite?
Seriously: If the database structure in 2.0 would greatly differ from
1.4 (which is to be expected), a rewrite of the core parts is in order.
* The parser will be rewritten anyway as XML-interpreting.
* We can probably keep the skin system
* Special pages will need a (partial) rewrite, depending on the new DB
structure
* Cache/squid/... can probably stay as they are
DATABASE REWRITE PROPOSAL
I vaguely remember there's one on meta, but I came up with this last
night (don't ask;-), so here goes nothing:
* Object list table. An object is a page (article, talk, etc.), an
image/media/binary file, or data; extensible with future types.
* A table for each object type, which holds the actual data: Article
text and user comment, revision number etc.
The object table only contains an ID and name (+namespace) for the
object, and an ID number for the actual object in its table.
So:
* OBJ_ID, OBJ_TITLE, OBJ_NAMESPACE identifies the object
* OBJ_TYPE (0 for page, 1 for image, 2 for data...)
* OBJ_DATA_REVISION identifies the current object data *in its table*
An article has
* ARTICLE_ID (matches OBJ_ID)
* ARTICLE_REVISION (both cur and old; OBJ_DATA_REVISION has the latest
ARTICLE_REVISION)
* the text of that revision, the user id, text and comment, and all the
other goodies
An image table would have
* IMAGE_ID, IMAGE_REVISION
* filename of the stored image, or reference to an external image
(commons), with a local description
Similar for data etc. (maybe even users?)
A table for changes would thus store an OBJ_ID. Recent Changes can then
look up what that object is, and then look up the changes in the
appropriate table.
As a result, we'd get
* an "universal" interface for everything we store in the wiki
* a (relatively) small table with all objects, equaling faster access
times, that only references the actual data (in the appropriate table)
Now you see why I think "rewrite" for this one. I also strongly believe
we should put *every* database access into the database class, capsuling
it from the rest of the software. Had we done this in 1.4, basically
only a rewrite of the database class(es) would be in order for the above
proposal.
Enough shocking you for now,
Magnus