I've been following the Java Content Repository story since the OSCOM conferences of old. Last week, I took a new look at it as Bertrand Delacretaz from Day held a JCR presentation in the Interactive Knowledge Consortium meeting. And you know what? Midgard and JCR resemble each other quite a lot:

• Both follow a repository-centric approach, where the content repository is the point of integration between different tools and applications, with signals flying to inform about actions performed. In JCR this is done with Java events, and in Midgard with D-Bus signals.
• Both are tree-based, enabling objects to be accessed either via their path in the tree, a UUID, or various queries. With JCR, the queries are typically XPath, while with Midgard there is the Query Builder.
• Both also provide a reasonably simple way to define new data types. In JCR's case the Node Type Notation has a somewhat Ruby-like syntax, while Midgard's MgdSchema uses XML. Unstructured data is supported in both by extending the content objects with additional attributes.
• Both provide the notion of a workspace, an ability to have multiple "virtual repositories" within one installation. In Midgard, this was originally implemented to support easier hosting and is called "Sitegroups".

There are some important differences, though:

• JCR is a Java-centric specification, with Apache Jackrabbit acting as the reference implementation. Midgard has only one implementation, but with bindings to multiple programming languages like Python, PHP and C#, allowing developers to work with the tools they are familiar with. Midgard APIs could of course be reimplemented natively in any of the languages, as was done with pure-PHP Midgard-Lite years ago.
• In JCR, everything is stored in a single content tree. In Midgard, the content tree can be multi-rooted, and there can be "independent" objects that exist outside the tree hierarchy.
• The JCR specification allows for version control, which in Midgard is handled using external tools.
• Midgard supports content replication, which JCR does not.
• Midgard handles internationalization of content objects as part of its API, but does not support multivalued properties as JCR does. To bridge this gap between the two repository APIs, I have posted a series of feature requests to Midgard's tracker.

Even with these differences, Midgard and JCR remain surprisingly similar on the conceptual level. It would be an interesting experiment to finally create the Midgard-JCR bindings that Jukka Zitting started long time ago.

Technorati Tags: jcr, midgard, repository