Lars Trieloff's Collaboration Weblog

The standard defines the core concepts like a content repository, document, folder, policy, object type and aspects of these concepts like versioning, operations on objects, etc. Additionally it two protocol bindings, namely SOAP and REST (a "variant" of the Atom Publishing Protocol has been chosen) two express these concepts.

Some confusion has been caused by the question what CMIS is not, which is also important in the definition of a standard. CMIS is not an API, this means developers of content centric applications might use CMIS, but they will never develop against it, they will use a programming library that implements either a CMIS client or a CMIS server framework and this API will be, depending on the exact client library, probably similar to the Java Content Repository API. CMIS does not deal with Administration and Configuration, so there will be no way of adding and removing content types using CMIS. CMIS does not cover Authentication, which means it is left to HTTP in the REST case or WS-Security 1.1 and Username Token Profile 1.1 in case of SOAP.

Following this short introduction into what CMIS is or is not, I have gathered a collection of articles, comments and announcements regarding CMIS that should give you a round-up of what people think about it.

• Microsoft has a press release covering the CMIS introduction that contains links to the actual spec somewhere.
• Bill de Hóra, one of the authors of the underlying Atom Publishing Protocol Spec notes that the spec is not entirely accessible: "I get to a page. In that page there is a link to a zip file. There is a jessionid in the URL. In the downloaded zip file there are PDF files. In the zip file there is also a folder. In this folder are many files."
• A bit more readable than the official PR babble is this blog post by Ethan Gur-esh, a Microsoft Program Manager, which says Microsoft won't say right now, when Microsoft Sharepoint will support CMIS - and completely omits the even more important question, when Microsoft Office will support it.
• Speaking of implementations Alfresco's John Newton is happy to announce the first implementation of CMIS, which is currently in the Alfresco Labs, as an experimental, not yet production-ready test implementation.
• Andrew Chapman discusses CMIS's potential as Another SharePoint Desilofication Solution, notes that it has the opportunity to increase interoperability at a certain level, but that it will take years until it sees the light of actual live production environments.
• This does not prevent C3 Associates to welcome Alfresco's experimental, not yet production-ready test implementation as the "live production implementation" of CMIS that you can have nownownow. Call me a sceptic.
• While we are welcoming, of course Day's David Nüscheler, spec lead of the Java Content Repository spec and one of the most vocal advocates of content unification is quick to say: "Welcome CMIS, congratulations!". It seems like he understands very well that JCR API and CMIS at a protocol can play together nicely.
• This view is shared by Kas Thomas of CMSWatch, who sees CMIS as a potential Lingua Franca of ECM, but still notes that this does not mean the end of APIs like JCR.
• Interestingly, Bex Huff expects to be tap-dancing "n the grave of that awful JSR170 standard", which means he either expect to program against a protocol or expected to exchange data between systems using an API. As I said, interesting.
• On the other hand, Craig Randall can offer more insight into CMIS and its opportunities with a podcast interview with Kyle McNabb, Analyst at Forrester.
• Following the "insightful" theme, Chuck Hollis says CMIS will not be just another standard, because content unification is a real problem and the big boys are backing it. And if the problem is not being solved by CMIS, it will be something very similar to it.
• Jeff Potts shares this view and links to the aforementioned experimental Alfresco implementation as well as to Apache Jackrabbit and Apache Sling, which has a RESTful content access protocol that, is not standardized, but should be. Perhaps Apache Sling will pick this protocol up and offer support for non-Alfresco, JCR-compliant repositories.
• To close this roundup, Larry Cannell sees that CMIS could lead to the commoditization of content management, which of course requires prior standardization and acceptance of content repositories as software infrastructure. But this is definitely the path that is outlined by efforts like CMIS. He does not fail to mention that CMIS is by no means an accepted and adopted standard, and only time can tell if it will become one.

What next steps should you take:

• if you are in the process of defining your own remote protocol for a content repository, you should have a close look at CMIS right now
• if you are a content repository vendor, you should wait. Now it is the task of Microsoft, IBM and ECM to put code behind their words and show that CMIS can fulfil the interoperability promise it makes
• if you are a developer of content centric applications, you have even more time to wait, because before you will professionally use CMIS it needs adoption, client libraries and customer demand.

This article is a part of Lars Trieloff's weblog. If you like this article please subscribe to my feed and get automatically notified of updates.