Extension:MirrorTools/Development

A complete rewrite of MirrorTools is in progress. It is a huge project, and there is some question of what is the best strategy of how to proceed.

Needed functionality

 * protect &mdash; so that we know whether to bother referring Wikipedia users to the Wikipedia edit page when they try to edit. (Of course, there's always the Override: namespace...)
 * delete &mdash; this will be done as just an informational log entry, and as an event that causes page control to pass from one wiki to the other.
 * upload &mdash; yup, we'll need to mirror these, unless we're going to rely on the instantcommons.
 * move &mdash; yup, we'll need this too, although the only revisions that will move will be the ones on the Wikipedia page that's being moved. In other words, suppose article X contains revisions 1, 2, and 4 (from Wikipedia) and 3, 5, and 6 (Inclupedia-only). Wikipedia article X moves to Y. Only revisions 1, 2, and 4 move; 3, 5, and 6 remain where they are and are buried under the new redirect to Y. Now suppose there already was an Inclupedia article Y that had revisions 7, 8, and 9. No matter; revisions 1, 2, and 4 get merged into its history. If Y subsequently gets moved to Z on Wikipedia, only revisions 1, 2, and 4 move to Z. You get the gist.
 * import &mdash; somehow we'll need to implement this.
 * patrol &mdash; it would be nice to include as an optional feature, although I'm not sure how much demand there will be for it.
 * merge &mdash; what is this? Some sort of user merging?
 * newusers &mdash; Yeah, we'll need this.

Change the core
Most of the core functions, e.g. LogPage::addEntry, lack a timestamp parameter. I could (1) add that parameter to those functions or (2) let those functions have the same list of parameters and add new functions that they call that have a timestamp parameter.

There are another two options as well; revising importing and exporting, or revising the API functions. Importing/exporting would be particularly good for editing, since there are so many edits. Right now, log actions are not importable/exportable but maybe I could change that.

What about MirrorBot?
There are two MirrorBots, MirrorPullBot and MirrorPushBot. MirrorPushBot will interface with MirrorTools. What is presently envisaged is that MirrorPullBot will poll the API of the remote wiki, get the data, and put it into a queue table in a database. Then MirrorPushBot will put that data into the local wiki via said wiki's API. Or, if MirrorPushBot runs on the server that has the local wiki's database, it could just do database queries to directly put that data in there, without fooling with the local wiki's API.

The ultimate goal
The ultimate goal of all this is to end up with a local wiki database that has everything (or at least everything that's needed) that's in the remote wiki database. Plus there needs to be capability to deal with synchronization problems.