Indeed, JCR has been playing and will keep playing a fundamental role in opening the doors of a domain that used to be the private hunting field of a few mammoth vendors. Of course, this is not about getting great repositories for free, instead the main benefits are allowing users to be in control of their content assets and enabling developers to build innovative content-driven solutions.
I did not have time to dig deep in the specification, but I noticed that observations now produce richer events (source path and indentifiers) and that the previous version of SQL and XPath query languages have been deprecated in favor of an Abstract Query Model (AQM) that incarnates in a new SQL (JCR-SQL2) and a query object model (JCR-JQOM). I was convinced that XPath was a perfect fit for JCR searching but apparently I was wrong! I think JQOM will be the more appealing option for tool builders as mapping query features to this object model will be less clumsy than generating SQL.
Now to my little wish list! As a user of the API, here are the three changes I would like to see in the new version. Some are trivial, like:
- A Property object can be single or multi-valued hence offers getValue() and getValues(). I find logical that calling getValue() on a multi-valued property fails but I find deeply counter-intuitive that calling getValues() on a single-valued property fails. By allowing getValues() to return a unique value from a single-valued property, the code needed to read property content would be vastly unified, thus simplified. This would also be conform to the principle of least astonishment.
- An Event has a type property that defines the reason why it was raised. This is defined by a list of static integer while I think it would be better to use a type safe enumeration, as it is done for PropertyType. I can understand that this change would create an ascending compatibility challenge so at least adding an helper class that could render to / parse from String would be very helpful for translating event types to a human readable form (PropertyType offers such methods: nameFromValue and valueFromName). On top of that, making Event serializable would also facilitate its processing.
- A less trivial addition would be to offer a unified way of acquiring a repository. Currently each vendor can offer a different client factory: writing an application that connects to several repositories forces to write specific code (or to use SpringModules). A unified URI-driven repository factory mechanism a la JDBC would be very helpful.
