incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florent Guillaume>
Subject Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Date Fri, 11 Dec 2009 18:44:01 GMT
On Fri, Dec 11, 2009 at 7:10 PM, Florian Müller <> wrote:
> But you are actually comparing two different levels of APIs. The opencmis-provider-api
handles simple immutable data objects while chemistry-api follows an object-oriented approach.
As far as I know Chemistry has nothing comparable to the opencmis-provider-api.

The Chemistry SPI class provides a data-transfer-object-based API that
is similar to opencmis-provider-api although implemented very

> The opencmis-client-api would be the right level to look at but the code of this API
is not in SVN yet. We will make available on Monday.
> The APIs are not the main reason why I think that Chemistry and OpenCMIS are different.
(I would like to avoid the word "superior". I never used that in this context. Both projects
came from a different background that's why they are different.)
> Chemistry uses Abdera to communicate with the server while OpenCMIS is based on JAX-B
and some CMIS specific XML coding.

Actually no, the Chemistry client side doesn't use Abdera, it uses an
ad-hoc StAX-based serialization. Currently the server side still uses
Abdera but I'd like to make this go away and use StAX as well, as
Abdera is very heavy and costly (and not well extensible).

>There is a lot of code sharing between the AtomPub and the Web Services binding. (I couldn't
find a Web Services client in Chemistry. So I can't comment on that.)

Indeed in Chemistry the AtomPub client code doesn't use JAX-B based
serialization so doesn't share code with SOAP. JAX-B makes for a lot
of intermediate objects whose structure depends on the XML you want to
generate, which is fine for SOAP but doesn't seem right to me when
designing an API from scratch. I wanted the APIs to be as Java-ish as
possible and hide the underlying XML structural choices as much as

>OpenCMIS has a caching infrastructure that is specific to CMIS and how OpenCMIS work.
There is nothing like that in Chemistry.

Yes Chemistry has no caching yet, this will be added later at the
level of the high-level API implementation. For me it's not the role
of the SPI to do caching.


> The overall architecture and principals below the API are very, very different. Bringing
both together would require philosophy changes on both sides. I'm not saying that this isn't
possible, but it's a lengthy process.
> We derived our design from a lot of prototypes and applications that we have built over
the past 20 months. Some code fragments and concepts are actually pretty old now. We had a
lot of it in one shape or another when Chemistry started. That's why Chemistry was never an
option for us. The code bases of Chemistry and OpenCMIS have been developed at the same time
taking different routes. Chemistry did that in the public, most of OpenCMIS was created behind
closed doors.
> Here we are with a working code base that we cannot give up and that we will maintain
in the future for obvious reasons. Our idea was to make it Open Source and let others benefit
from our work. Apache seemed to be the right place - at least three days ago. It was never
meant to be an attack against Chemistry.

Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)   +33 1 40 33 79 87

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message