Hi, 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. Florian -----Original Message----- From: Goetz, Paul [mailto:paul.go...@sap.com] Sent: Thursday, December 10, 2009 9:20 AM To: general@incubator.apache.org Subject: RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS) 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, Paul -----Original Message----- From: Gianugo Rabellino [mailto:gian...@gmail.com] Sent: Mittwoch, 9. Dezember 2009 18:45 To: general@incubator.apache.org Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS) On Wed, Dec 9, 2009 at 6:33 PM, Bertrand Delacretaz <bdelacre...@apache.org> wrote: > On Wed, Dec 9, 2009 at 6:21 PM, Goetz, Paul <paul.go...@sap.com> 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 will >> be very hard to do - but on a mid-term perspective, we will review our >> options to merge >> 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 bit. -- Gianugo --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
