Midgard has had replication capability since late 1999. First replication was handled with the Repligard command-line tool. Then in 2005 we got the Java-based Exorcist tool that was able to do cross-CMS replication. But both of them suffered from being slightly external of the normal Midgard environment.
To support that we’ve now been working on a midcom.helper.replicator library that handles the issues of solving what to replicate, where and how. The library has been made with a modular toolbox philosophy where each replication pipeline is stored as a “subscription” that defines what exporter, transporter and importer should be used.
Some example cases here:
Staging/live: the subscription is configured to use an exporter that checks for object approval before exporting, and a transporter that directly sends the data to the live server via HTTP
Automatic backups: you can create a replication subscription that will send all database changes as XML packages to your Gmail account for free off-site backup
Collaboration on specific items: we could define a “wiki collaboration” exporter that you could use to exchange wiki pages between other project parters
Now the export and transport ends are mostly done and we’re today focusing on integrating the importers with the MidCOM DBA layer to get the benefit of watchers, ACLs and other checks in the import end.
I’ll update this post with more details as we go.
Random thought: Midgard vs. Drupal communities
Looking at Ohloh statistics, Midgard has had 38 contributors since 2001 when we switched repositories, while Drupal has had 589 contributors. With this huge disparity of numbers it is a bit difficult to understand how Midgard has 207 person years behind it, while Drupal only has had 113. Midgard also has a lot more code. I guess Midgard contributors just are more productive. Maybe this has something to do with the power that the framework gives us?