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
