Here is a short presentation with my personal top ten features in our upcoming release. Of course, this would ideally be accompanied by short fast paced demos, so if you are interested in getting personalized demo or a video, please reach out to us.
Entries by David Nuescheler
Today I had the opportunity to speak at the JBoye conference in Aarhus. It was a pleasure as every year since the audience and speakers really constitutes a who-is-who of WCM visionaries and insiders. I am definitely looking forward to coming back next year.
|72||individual members of the expert group|
|3||ballots of the executive committee of the JCP|
|277||pages of spec|
|87||interfaces and classes|
|522||fields and methods|
|1895||testcases in the official TCK|
|100%||signature coverage of the TCK|
|2.0||Content Repository for Java Technology API
This brought the opportunity to compare and differentiate the two efforts for with a unique legitimacy. There seems to be a desire to discuss the relationship between CMIS and JCR similar to the desire to discuss JCR and WebDAV or, more recently, JCR and Atom. So far, JCR and CMIS have been compared in what I would call "a less educated fashion" for example in the CMIS v0.5 spec draft. Most of those comparisons have been corrected in the meantime.
Feel free to view the entire slideshow here, but here are the main points:
API vs. Protocol
JCR specifies an API (Application Programming Interface) while CMIS specifies two protocol bindings. Much like the Servlet API in Java and the HTTP protocol are complementary this is also the case for JCR and CMIS. Similar arguments have been made for Atom and WebDAV. JCR and CMIS are complimetary in this aspect.
Focused Model vs. Generally Applicable Model
JCR specifies a very general model based Node and Properties that lends itself to the implementation of specific domain models. On the hand, CMIS specifies such a specific domain model for document management.
The CMIS domain model can easily be implemented in a JCR model (see next point). Some people could say that if one were to implement CMIS from scratch a JCR repository would be the ideal starting point as it provides the perfect infrastructure to do that.
I think it is one of the most important assets of CMIS that it exposes the domain model of document management. It will be helpful in further standard discussions to have an established consensus on the domain model amongst the document management vendors.
Every JCR repository is a CMIS repository
Based on this type of compatibility between CMIS and JCR Apache Chemistry (currently in incubation) implements CMIS on top of JCR (amongst other things). This turns every JCR compliant repository into a CMIS compliant repository without any development effort. Even better news are that Chemistry gets bootstrapped with numerous existing JCR repositories and connectors. These repositories can thus expose CMIS right from the start.
Interop vs. Infrastructure
Something that I learned during the years of specifying JCR: There is always a tension in a specification to address both "interop" and "infrastructure" needs. Interop enables different repositories to be compatible on some level, whereas infrastructure provides users with a platform to build upon.
There were tendencies in the JCR expert group to support users of the API in a way that they could build real-life applications. Hence, the infrastructure aspect was always a very important aspect. Because of that, the least common denominator aspects that come with "interop" were only a part of the equation.
For CMIS, offering general purpose infrastructure is a stated non-goal. CMIS is only concerned with "interop".
Consequently, JCR is very successful with the number of users and applications built on top of JCR, while I believe that it is the goal of CMIS to be very successful with number of implementations.
In terms of perception I think CMIS reduces the expectation on JCR to be a least common denominator interop spec. I welcome that because both specification efforts will be able to evolve in a more agile fashion when they focus on "interop" and "infrastructure" needs respectively.
In summary, I am very excited to have a specification both on the protocol and on the API level addressing the needs of a more open standards based content management landscape.
Dear CMIS community,
As per the "official invitiation" ;) email below we are hosting an CMIS PlugFest in Basel. Since this is not constrained by OASIS TC membership we would like to make this as open as possible and invite other interested parties as well. Come along, bring your CMIS implementation and see if it interoperates with others.
Please let me know if you intend to join us (david(at)day.com). If you have not been to Basel before see Roy Fielding's "Visitor's Guide to Basel".
---------- Forwarded message ----------
From: David Nuescheler
Date: Sun, Apr 5, 2009 at 12:58 PM
Subject: Official Open CMIS PlugFest Invitation April 29-30 in Basel, Switzerland
Dear TC Members,
Please find below the "official" invitation to the frequently disussed CMIS Plug Fest at the Day offices in Basel, Switzerland in April.
We would like to invite all CMIS TC members and other interested parties to an open PlugFest at our Offices in Basel Switzerland. (http://is.gd/qPs0)
9-17h Setup and Connectivity Setup, Smoke Tests
19h- CMIS Dinner
9-16h Actual Testing and compliance reporting
16h-17h Wrap-up, Next steps
We will provide wireless access to the Internet and we will also have inbound HTTP access through a reverse proxy ready for people to do remote testing to our servers.
For people who would like to check in remotely, we will use the following webex conference.
---< CMIS Plugfest >----------------------------------------------------------
Monday, April 29, 2009, 9h00 CET, 03:00 am EST, 12:00 am PST
Meeting Number: 709 533 911 (Password: day)
Dial-in: USA +1 (718) 354 1382
More Dial-in numbers:
For planning purposes it would be great if you could let me know (either on this list or directly) by the beginning of next week if you plan to attend and if you have any further questions please feel free to ask.