(was: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS))
Hi Jens, thanks for pointing out the differences in the codebases. I think all the points that you raise point into the direction of the fact that the code of the opencmis proposal is mature and and well thought through, which is absolutely great. ...and as you point out there there are definitely areas that the chemistry code could improve and be extended. Personally I am more than happy to support the evolution of the current chemistry codebase as soon as feasible into the directions you describe. I think these are all good points that you bring up. Of course I will leave Florent and some of the other more regular committers who are definitely more intimate with the code to make comments but I would really assume that we do not have any fundamental architecture differences, but it is just the case that in the chemistry codebase we have not gotten around to doing some of those things. Sounds like great news to me to get architecture discussions like these discussed in the open and see how much of an alignment we can get... regards, david On Sun, Dec 13, 2009 at 7:44 PM, Jens Hübel <[email protected]> wrote: > 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 > > > > > > > > -- David Nuescheler Chief Technology Officer mailto: [email protected] web: http://www.day.com/ http://dev.day.com twitter: @daysoftware
