Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of fguillaume@nuxeo.com
 designates 209.85.218.210 as permitted sender)
MIME-Version: 1.0
Date: Thu, 10 Dec 2009 16:00:42 +0100
Message-ID: <646a352f0912100700q5bc45268vebaa75cbf56c7269@mail.gmail.com>
Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
	Interoperability Services (CMIS)
From: Florent Guillaume <fg@nuxeo.com>
To: List-Chemistry <chemistry-dev@incubator.apache.org>,
	Incubator-General <general@incubator.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I'm cross-posting this to general@ and chemistry-dev@.

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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org