RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)

[Jens Hübel <jh...@opentext.com>]

Hey Jukka,

let's discuss some of the technical areas how to continue.

> Would it at least make sense for the projects to share a common
> org.apache.cmis package with with things like constants defined in the
> CMIS standard and other basic concepts that everyone can agree with?

Definitely there are areas where sharing makes sense. The constants, etc are probably the simplest pieces. I see some more:

Query Parser:
Chemistry did a pretty good job with the query parser. Currently with focus on client side maybe not on our top list, but I do not see any reason to implement this a second time. And this is one of the more complex sub-projects.

Web Service: 
Not sure how far you are here. But the provider implementation should be functional complete in regards of the WS binding. You should take a closer look if you see any chance to benefit from this.

Caching:
If I got it right there is no Caching yet in Chemistry. Caching (at least of the type system) is probably crucial for an acceptable performance of any CMIS implementation. We already have some form of caching, perhaps not yet the most sophisticated one. This will highly depend on the internal object structure that is cached, but I assume that at least parts of the code can be shared.

This list isn't complete but this comes into my mind right now.

We also should outline some more of the design differences:

> Indeed in Chemistry the AtomPub client code doesn't use JAX-B based 
> serialization so doesn't share code with SOAP.

This is very different compared to the OpenCMIS approach. Both bindings use the same XML and our intent was to share as much as possible between SOAP and Atom and keep the binding specifics to a minimum. The consumer of the API should not see a difference between the two bindings. On top of the JAXB generated class we have handcrafted APIs and implementations. As Florian pointed out we favor a two-level approach here with data transfer classes (being stateless with the exception of caching) and a stateful object-oriented client API.


Testing:
As mentioned above the client should not be aware of the binding in use. Our tests are therefore consumers of the API and agnostic to the binding. There would be an ObjectServiceTest but not an AtomXYZtest. What I see in Chemistry is a TCK based on AtomPub and directly operating on feeds etc. Is it intended to continue this way or is this more an interim step (you need to start with testing somewhere)? BTW our code isn't totally clean in this regard as well yet.

AtomPub and Web Service:
Looking at the chemistry code this seems to be (currently) focused very much on AtomPub. One of the OpenCMIS design goals is to treat both protocol bindings equally. WS is a first class citizen for OpenCMIS. What are the plans for Chemistry in regards of web services?

And as far as I remember one question is still unanswered: 
What is the intended way in Chemistry how a client API consumer controls when a request to the server is made? Do you have any design around this so far? 

Jens