Doodling with JSR-170

tl;dr

Th JSR-170 specification, also called "Content Repository for Java(TM) technology API", is somewhat painful to work with from within the Zope and Python world.

A "War and Peace" API

The spec is available here and provides some 300 pages of heavy sledding.

Amusements Galore

In particular, it is entertaining to see the hoops they have to jump through to get "dynamic typing" working from within the shackles imposed by Java. They devise a set of class-like type definitions (node types, property types, even an abstract item type as a base), including subobject and attribute specifications and constraints, and have lots of isinstance / issubclass sorts of APIs among them.

Interesting Use Cases

Beyond the entertainment value of watching B&D language bigots reinvent loose / dynamic typing, the real reason for pursuing this API is that it promises to be a gateway for content migration. Such migration has a couple of interesting use cases:

  • Upgrading from an older version of your CMS to a newer one, with subtly incompatible constraints / schemas. Dump + reload is the classic pattern used by RDBMS vendors to escape the "nowhere to stand" problem, and could help us, too.

  • Migrating content from one CMS platform to another. I think both Lenya and Midgard have some support here, and the spec itself has committee members representing many of the big, proprietary vendors. Being able to do such an export might be enough risk reduction to make a "pilot" project palatable to customers who are evaluating competing platforms, since they don't risk losing their content.

  • Handling staging of content is another possible win.

This is basically the same set of usecases for Zope3's filesystem synchronization, with (potential) interoperability thrown in as lagniappe.

Tool-friendly XML?

A downside: the "lossless" representation (the spec's "system view") is not any friendlier to filesystem tools than Zope's XML pickles (in fact, it is probably isomorphic with them!)

Python Mapping

As I worked my way through it, I modeled the API as a set of Python modules, with zope.interface interfaces for each of the components. I have uploaded a snapshot and would appreciate comments from those who have also worked with the spec. Subversion for the work is currently:

svn+ssh://svn.zope.org/specialprojects/paris/jsr170

Future Plans

I intend to continue experimenting with my mapping, including a couple of possible avenues:

  • Writing Five-based adapters for OFS.SimpleItem, OFS.FOlder, OFS.File, PythonScript, ZopePageTemplate, etc. I have started down this path, but don't yet have anything interesting to show.

  • Writing Five-based adapters / utilities for CMF content, including the ability to round-trip content.

  • Implementing more of the spec in Zope3 itself, where the extra semantics (versioning, for instance, and the API's "session" concept) might be less entangled than in a Zope2 setting.