The second day of the CMIS PlugFest was less about setting things up than actually trying to fill the grid of possible tests (over 28 possible tests) that cover all the combinations of client and server implementations that were available there.

I was myself hacking most of the day to get a brand new CMIS client implementation up and running, and I got the first unit tests working against both the Alfresco CMIS server and the Day CRX server. I even managed to navigate through the whole repositories. I then went on to work on the integration with Jahia, to be able to browse those repositories directly from Jahia's file manager. Unfortunately, despite the amount of code that was produced in the last 24 hours, it just wasn't possible. Despite this I believe this is really close to happening, and we should have something experimental to test against the various servers quite soon.

The good news of the day came from Jukka Zitting that was visiting the PlugFest, and that announced that Apache Chemistry was officially accepted by the Apache Foundation as an incubator project, and so over the course of the week-end Florent Guillaume, from Nuxeo, who contributed most of the code for Chemistry, will finally be able to commit all this work and let the community hack away at it.

We were also joined during the day by IBM who was also providing a server against which to test. We had very interesting discussions about what was needed in the CMIS specification. A few of us believed that CMIS should really make usage of JSON, and it seems that a proposal for going in that direction might just happen, but it must happen fast, as there is a lot of pressure to get CMIS 1.0 out the door soon.

The idea behind using JSON with CMIS is quite a natural one. Why have to deal with all the XML parsing involved in Atom Pub and Web services when you could use the extremely simple JSON format to exchange all the data you need ? I really hope that this will be added to CMIS as this could make it one of it's most flexible bindings. It is much simple to develop lightweight CMIS clients without the need for XML parsing. I'm mostly thinking of PHP, Javascript and other technologies.

In the interoperability tests, search was still a problem for many clients and servers, and this was of course expected as it is the most complex part to implement. This also means that it will be necessary in the near future to perform another interoperability PlugFest to go further into the testing and make sure that even search works properly.

The day was concluded with demonstrations of a few combinations of client and servers. Among the demonstrated clients were : Chemistry Javascript against Day CRX + Chemistry, SourceSense's CMIS Portlet against Alfresco, the CMIS Flex Explorer against Alfresco (which was also the client that worked against most of the servers !), OpenText's C++/Java client that integrates with Windows Explorer, Outlook and MS Word, and last but not least SAP's client that plugs into an existing infrastructure of explorer tools that plug into various SAP backend repositories (CMIS or not) and also exposes all the various back ends as WebDAV resources. This made me smile because there has been a lot of discussion wether CMIS should have a WebDAV binding, and basically SAP was demonstrating WebDAV on top of CMIS :)

During the demonstrations, a lot of discussions were focused on making sure that the points that were problematic to implementors were noted and then discussed in the OASIS TC. Among those points were the upload mechanism of binary data that is not very clear when using the Atom Pub binding, because there are two ways of doing this, and therefore this is confusing to client implementors. The second point concerned path navigation, and the fact that CMIS currently doesn't offer a way to lookup a content object by it's path. Currently, when given a path, the CMIS client implementations must navigate from the parent path down to all the descendants to find the object corresponding to the path, which is not very speed efficient.

It will be very interesting to see if these points can be adressed efficiently to avoid side tracking the specification. It seems that major vendors such as IBM, Microsoft and EMC want CMIS to be completed in Q3 2009, so this doesn't leave much time to solve issues.

All in all, I'd like to thank Day for hosting this PlugFest. This event, although not too certain how it would happen initially, turned out to be really necessary, and gave a really good picture of the real state of the CMIS interoperability. It is certain that this must happen again, when implementations are more mature, and especially when Apache Chemistry is fully available and ready to be tested. I would also like to thank Dave Caruana (Alfresco), who has been really great, helping me out with getting my tests up and running.

Day 1 started with some informal introductions, and setup of the existing servers. We now have OpenText, Alfresco and Jackrabbit+Chemistry servers up and running, and are running interoperability tests against those using a variety of clients, including OpenText that has a C++ plugin that connects Windows Explorer and as well as Office tools to CMIS back ends, SAP, Alfresco test units, two Flex-based clients (CMIS Explorer and CMIS Spaces), a Apache Chemistry CMIS Javascript client written by David Nuescheler at Day, an Apache Chemistry Java client that Florent Guillaume (Nuxeo software) is working hard on to commit hopefully before the end of the week.

It's really great to see so much effort going into interoperability tests. The most interesting thing about CMIS is the momentum behind it, more than the technology, that will probably still evolve over the year. It is also very important to get the first version of the specification out as early as possible, because so many specifications fall into tech-limbo, to never be completed (802.11n, etc...).

Apache Chemistry is also looking better than ever, having just been accepted into the incubator at Apache, and the code will probably be committed over the week-end. From then on hopefully the community will be able to have a look at it. This will also help interoperability, as even major vendors could use this code base to ensure compatibility.