On Fri, Dec 11, 2009 at 7:10 PM, Florian Müller <fmuel...@opentext.com> wrote: > 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 Chemistry SPI class provides a data-transfer-object-based API that is similar to opencmis-provider-api although implemented very differently. > 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. Actually no, the Chemistry client side doesn't use Abdera, it uses an ad-hoc StAX-based serialization. Currently the server side still uses Abdera but I'd like to make this go away and use StAX as well, as Abdera is very heavy and costly (and not well extensible). >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.) Indeed in Chemistry the AtomPub client code doesn't use JAX-B based serialization so doesn't share code with SOAP. JAX-B makes for a lot of intermediate objects whose structure depends on the XML you want to generate, which is fine for SOAP but doesn't seem right to me when designing an API from scratch. I wanted the APIs to be as Java-ish as possible and hide the underlying XML structural choices as much as possible. >OpenCMIS has a caching infrastructure that is specific to CMIS and how >OpenCMIS work. There is nothing like that in Chemistry. Yes Chemistry has no caching yet, this will be added later at the level of the high-level API implementation. For me it's not the role of the SPI to do caching. Florent > 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. > > -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
