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 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. Florian -----Original Message----- From: Jukka Zitting [mailto:jukka.zitt...@gmail.com] Sent: Friday, December 11, 2009 5:24 PM To: chemistry-dev@incubator.apache.org Cc: Incubator-General Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS) Hi, On Fri, Dec 11, 2009 at 4:44 PM, Florian Müller <fmuel...@opentext.com> 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. BR, Jukka Zitting
