Hi, I'm cross-posting this to general@ and chemistry-...@.
First let me say that I'm glad to see companies willing to open-source their projects, that's always a good thing for the open source world in general. I also understand that there is an existing and used codebase from these companies and that it makes things less flexible for them. Paul and Florian contacted me privately last month to weight their options regarding their client-side codebase for CMIS that they were considering open-sourcing. I gave them my personal views but did not discuss this even on the private Chemistry committers list as I was told that this was still a non-public matter for SAP and Open Text. Now, regarding the scopes of the projects. For Chemistry, let me point you to a blog article I wrote in the past that describes this: http://blogs.nuxeo.com/dev/2009/06/promises-modern-chemistry.html Basically Chemistry aims at being a set of libraries to help Java programmers use CMIS from the client side or the server side. Some Javascript bindings have been contributed but at this stage they aren't really maintained, so I consider them anecdotal. I've seen it mentioned in this thread that Chemistry has ties to JCR: this is not true. While a partial server implementation for a JCR backend exists, nothing in Chemistry restricts you to using this, and actually Nuxeo has its own bindings, and I believe other companies like EntropySoft or In-integrierte Informationssysteme GmBH are using it with their own non-disclosed backends as well. So please don't think that Chemistry is actually restricted to JCR. The scope of the proposed OpenCMIS is a complete subset of the scope of Chemistry. Chemistry also provides protocol handling to AtomPub and SOAP (in addition to many other things), and separates its layers in a SPI (the OpenCMIS Provider) and API (the OpenCMIS Client layer). The goal of the Chemistry API is also, like Florian says, to provide "all the classes and methods you would expect from an object-oriented interface". This API already exists, and as OpenCMIS is currently designing theirs it would be a shame if no exchange or reuse was done on this side. Chemistry is willing to improve its API in any direction if it helps others and has sound technical merits. For some specific points raised in the thread: Paul wrote: > 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. Chemistry is certainly open to clarifications and better interfaces or controls when there are needed. The SPI/API separation is complete in Chemistry, these are two separate interfaces. I'm not sure what Paul is referring to, if things can be clarified then let's. Gianugo wrote: > Let me see if I'm getting it straight - what you are saying is that it > would be hard to decouple Chemistry from JCR so that you might use it > for another server implementation? If that's the case, I (kinda, as > JCR should be pretty OK to that extent) see your point - otherwise I'm > a bit lost I'm afraid. Chemistry doesn't have any coupling at all with JCR. My earlier recommendation to Paul and Florian, and my recommendation today, is that, if incubating is deemed the better choice, OpenCMIS become a top level directory under the Chemistry codebase. The earlier the two codebases are brought together, the earlier we can start factoring things (and there are quite a few boilerplates in the CMIS spec). IMHO it would also be nice if the high-level APIs could converge, as they are what the Java programmer will see and, when it makes sense, we should reduce confusion. But this kind of statement worries me: "We are currently designing the API of this layer. The proposals are not public yet." I don't see this (or the fact that the code has not be released in any public manner yet) as a good commitment to embracing open source. I'm worried about how in the future code changes that would clarify APIs or refactor things may be rejected because the library is already used in SAP or Open Text's projects and this would cause them difficulties. Regards, Florent -- 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
