incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <>
Subject RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Date Fri, 11 Dec 2009 18:10:38 GMT
Hi Jukka,

In the end the APIs should be somewhat similar since they are implementing the same spec.

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 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. 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.) OpenCMIS has a caching infrastructure that is specific to CMIS and how OpenCMIS
work. There is nothing like that in Chemistry. 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

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.


-----Original Message-----
From: Jukka Zitting [] 
Sent: Friday, December 11, 2009 5:24 PM
Cc: Incubator-General
Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services


On Fri, Dec 11, 2009 at 4:44 PM, Florian Müller <> wrote:
> The only way to overcome this is to merge the OpenCMIS code into the
> Chemistry code base. But the technical approaches of the projects are so
> different that this might not work - at least not in the short term.

I compared opencmis-provider-api to chemistry-api. While there are
differences in design (granularity of interfaces, type safety, etc.),
the fundamental architecture is the same for both projects. This is as
expected as they both map the same standard to Java.

Are there some specific reasons why one design is superior to the
other? The only major difference I could quickly spot is the
ExtensionsData structure that OpenCMIS seems to include in almost all
method signatures. Other than that it looks like it would be fairly
straightforward to map from one API to another.


Jukka Zitting

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

View raw message