Paul, thanks for your reply. Some quick comments:

On Thu, Dec 10, 2009 at 9:19 AM, Goetz, Paul <paul.go...@sap.com> wrote:
> Hi Bertrand, hi Giuanugo,
>
> we discussed that with Florent Guillaume (from Chemistry) already.
>
> There are two aspects here, let me start with the technical one:
> As stated in the proposal: Chemistry aims to have a broader scope (including 
> server implementations and mappings to JCR). OpenCMIS is about protocol 
> handling (SOAP and AtomPub) only.

>From 10.000 feet, it seems like OpenCMIS might be used by Chemistry, then?

> 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.

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.

> The second aspect is organizational:
> It will be difficult to align the APIs right now. When discussing that with 
> Florent we came to the conclusion that either we start a sandbox in 
> Chemistry, or we start a project in parallel.
> After some further discussions (involving Justin Erenkrantz to get some 
> guidance), we decided for a new project to avoid the confusion of having two 
> API approaches in one project.
> Therefore we would suggest to start with a new podling, and decide on how to 
> do a merge/combination of Chemistry and OpenCMIS later.

I wish this discussion happened on chemistry-dev, and I would actually
like to see what the community as a whole thinks about it. I'd
actually prefer to see OpenCMIS possibly spinning off from Chemistry
after an unsuccessful integration attempt rather than merging at a
later time.

> And there are other Apache products co-existing in parallel (e.g. Axis and 
> CXF, just to pick one example), and the ASF has never stated that this has to 
> be avoided. So to me, it seemed that the idea of having two projects in 
> parallel isn't that bad.

Oh, there are plenty, and duplication isn't inherently bad. The
difference here (and it's a big one in my book) is that we are talking
about two different podlings, with all the related issues of
incubating projects such as finite resources and whatnot. And the fact
they both aim to implement an unfinished spec doesn't quite help.

May I suggest we move this discussion to the Chemistry lists in order
to seek consensus over there? That would allow you to return to the
Incubator with a proposal  properly addressing the duplication issue.
If there is a thorough discussion over there, and a general agreement
(including agreeing to disagree), I'll be happy to sign up as a
mentor/champion for OpenCMIS.

-- 
Gianugo

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to