Jackrabbit is now a full Apache project, and Jackrabbit 1.0 is released. Jackrabbit is a reference implementation of Java API called the Java Content Repository (JCR). A repository that stores JCR can be used to store arbitrary data, just like a database can, but it's more flexible. Instead of storing data in tables, a JCR repository stores data in a hierarchy of nodes and properties. JCR can replace JDBC in many applications that require a structured repository.

Cosmo uses JCR to store shares, calendars, events and other resources. The reason we use JCR instead of a database is because JCR has a more flexible data model, and because a hiearchical data model is closer to the data models of iCalendar and the Web. There are lots of applications today that use databases when hierarchical storage would be a more appropriate model, but databases are so standard that it's still going to take a while for this alternative to gain ground. It's important to have a standard API for accessing this new kind of repository, so that a server implementation doesn't get locked into one back-end.

As with all new technologies, the reality still falls slightly short of the promise.

• Cosmo has had to compensate for performance issues, particularly if a node has many child nodes. Flexibility has a cost, though I expect this will be improved over time.
  


• JCR implementations are still rather new and I'm not aware of much interoperability testing, so we don't expect we would actually be easy to replace Jackrabbit with another JCR implementation and just have Cosmo work. Still, it wouldn't be terrible either.


• According to BCM, both the XPath and the SQL query syntaxes that JCR provides didn't quite suffice for doing the kind of date queries we do, so BCM had to work around JCR to do time-range queries for calendaring. This kind of trick, bypassing the standard API to use the repository's own non-standard API, obviously makes the replacement issue more difficult.