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 Thu, 10 Dec 2009 09:03:29 GMT

I can talk a bit about the OpenCMIS architecture. That might help to distinguish it from Chemistry.

OpenCMIS consists of two layers. We call them Provider layer and Client layer.

The Provider layer implements and hides the CMIS bindings. The API of the Provider layer maps
the CMIS domain model. That is, the CMIS specification can be used as the documentation of
the Provider layer. There are the same services, the same operations and the same parameters.
The AtomPub and Web Services bindings are hidden behind this API. The application does not
need to know in advance which binding it will eventually use.

This layer is fully implemented expect for some details. There are some open spec issues that
prevent us from finalizing it. It needs extensive testing, though.

Although the Provider layer allows fine-grained control over the calls to the CMIS server
it doesn't provide a nice Java-like interface. It deals with immutable data objects.

The Client layer sits on top of the Provider layer and provides this nice Java-like interface.
It has all the classes and methods you would expect from an object-oriented interface. We
also will make sure that it fits into enterprise framework environments.

We are currently designing the API of this layer. The proposals are not public yet.

Application developers can choose which API is the most suitable for their use case. If fine-grained
control or cachable and serializable objects are relevant than the Provider layer is the right
choice. If a nice interface and framework integration is important the Client layer is the
better option.

Regarding the instability of the CMIS spec: Yes, there are still open issues but those are
details. We and other companies were confident enough to spend at lot of energy to implement
CMIS and do these small corrections later. It's the right time to implement the CMIS spec.

I hope that helps.


-----Original Message-----
From: Goetz, Paul [] 
Sent: Thursday, December 10, 2009 9:20 AM
Subject: RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services

Hi Bertrand, hi Giuanugo,

we discussed that with Florent Guillaume (from Chemistry) already.

There are two aspects here, let me start with the technical one:
As stated in the proposal: Chemistry aims to have a broader scope (including server implementations
and mappings to JCR). OpenCMIS is about protocol handling (SOAP and AtomPub) only.
At least to me (as a CMIS consumer), Chemistry is difficult to understand since both parts
(SPI and API) are not clearly separated. With OpenCMIS, we aim for a clear separation between
provider interfaces (SPI) and client interfaces (API). What's also missing from my perspective
is a better mechanism for the client to control the write-through operations behind the objects.

The second aspect is organizational:
It will be difficult to align the APIs right now. When discussing that with Florent we came
to the conclusion that either we start a sandbox in Chemistry, or we start a project in parallel.
After some further discussions (involving Justin Erenkrantz to get some guidance), we decided
for a new project to avoid the confusion of having two API approaches in one project.
Therefore we would suggest to start with a new podling, and decide on how to do a merge/combination
of Chemistry and OpenCMIS later.

And there are other Apache products co-existing in parallel (e.g. Axis and CXF, just to pick
one example), and the ASF has never stated that this has to be avoided. So to me, it seemed
that the idea of having two projects in parallel isn't that bad.

Best regards,

-----Original Message-----
From: Gianugo Rabellino [] 
Sent: Mittwoch, 9. Dezember 2009 18:45
Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services

On Wed, Dec 9, 2009 at 6:33 PM, Bertrand Delacretaz
<> wrote:
> On Wed, Dec 9, 2009 at 6:21 PM, Goetz, Paul <> wrote:
>> ...Alignment
>> Apache Chemistry aims to build a CMIS implementation, too. The focus for OpenCMIS
is to provide a
>> self-contained client library for CMIS for Java only - while Chemistry is aiming
at a broader scope, as
>> it started from a JCR/Jackrabbit based approach and is planning to support Javascript
as well.
>> As the APIs are pretty different right now, contributing the OpenCMIS code to Chemistry
>> be very hard to do - but on a mid-term perspective, we will review our options to
>> OpenCMIS with Chemistry....
> I'm not sure if having two podlings implementing CMIS is a good idea.

I second that. Although I am, in principle, interested, I'd like to
know more about what would differentiate OpenCMIS from Chemistry, and
why is this duplication a good thing. From your proposal, I seem to
understand you are more focused on the CMIS client side, yet I would
like to understand a bit more what's missing from the client Chemistry


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

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

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

View raw message