Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of fmueller@opentext.com
 designates 149.235.128.48 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PROPOSAL] OpenCMIS incubator for Content Mangement
 Interoperability Services (CMIS)
Date: Thu, 10 Dec 2009 10:03:29 +0100
Message-ID: <56C255F88C54014E92512ED3E7848F9404609D6B@MUCXGC1.opentext.net>
In-Reply-To: 
 <2CDD44F49E3D47459EB0282354AE42AE22ADC99AD0@DEWDFECCR05.wdf.sap.corp>
Thread-Topic: [PROPOSAL] OpenCMIS incubator for Content Mangement
 Interoperability Services (CMIS)
Thread-Index: Acp492xIUPEi8QQLQiG8OBXh651h1gAdHm6AAALB5FA=
References: 
 <2CDD44F49E3D47459EB0282354AE42AE22ADC47842@DEWDFECCR05.wdf.sap.corp>
 <f767f0600912090933w494ef7b9y81c96455d92b5b5b@mail.gmail.com>
 <7557e99f0912090945o49a764f9yb1c3f5010a956bc@mail.gmail.com>
 <2CDD44F49E3D47459EB0282354AE42AE22ADC99AD0@DEWDFECCR05.wdf.sap.corp>
From: =?iso-8859-1?Q?Florian_M=FCller?= <fmueller@opentext.com>
To: <general@incubator.apache.org>

Hi,

I can talk a bit about the OpenCMIS architecture. That might help to =
distinguish it from Chemistry.

OpenCMIS consists of two layers. We call them Provider layer and Client =
layer.

The Provider layer implements and hides the CMIS bindings. The API of =
the Provider layer maps the CMIS domain model. That is, the CMIS =
specification can be used as the documentation of the Provider layer. =
There are the same services, the same operations and the same =
parameters. The AtomPub and Web Services bindings are hidden behind this =
API. The application does not need to know in advance which binding it =
will eventually use.

This layer is fully implemented expect for some details. There are some =
open spec issues that prevent us from finalizing it. It needs extensive =
testing, though.

Although the Provider layer allows fine-grained control over the calls =
to the CMIS server it doesn't provide a nice Java-like interface. It =
deals with immutable data objects.

The Client layer sits on top of the Provider layer and provides this =
nice Java-like interface. It has all the classes and methods you would =
expect from an object-oriented interface. We also will make sure that it =
fits into enterprise framework environments.

We are currently designing the API of this layer. The proposals are not =
public yet.

Application developers can choose which API is the most suitable for =
their use case. If fine-grained control or cachable and serializable =
objects are relevant than the Provider layer is the right choice. If a =
nice interface and framework integration is important the Client layer =
is the better option.

Regarding the instability of the CMIS spec: Yes, there are still open =
issues but those are details. We and other companies were confident =
enough to spend at lot of energy to implement CMIS and do these small =
corrections later. It's the right time to implement the CMIS spec.


I hope that helps.

Florian


-----Original Message-----
From: Goetz, Paul [mailto:paul.goetz@sap.com]=20
Sent: Thursday, December 10, 2009 9:20 AM
To: general@incubator.apache.org
Subject: RE: [PROPOSAL] OpenCMIS incubator for Content Mangement =
Interoperability Services (CMIS)

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

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.

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.

Best regards,
Paul

-----Original Message-----
From: Gianugo Rabellino [mailto:gianugo@gmail.com]=20
Sent: Mittwoch, 9. Dezember 2009 18:45
To: general@incubator.apache.org
Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement =
Interoperability Services (CMIS)

On Wed, Dec 9, 2009 at 6:33 PM, Bertrand Delacretaz
<bdelacretaz@apache.org> wrote:
> On Wed, Dec 9, 2009 at 6:21 PM, Goetz, Paul <paul.goetz@sap.com> =
wrote:
>
>> ...Alignment
>> Apache Chemistry aims to build a CMIS implementation, too. The focus =
for OpenCMIS is to provide a
>> self-contained client library for CMIS for Java only - while =
Chemistry is aiming at a broader scope, as
>> it started from a JCR/Jackrabbit based approach and is planning to =
support Javascript as well.
>> As the APIs are pretty different right now, contributing the OpenCMIS =
code to Chemistry will
>> be very hard to do - but on a mid-term perspective, we will review =
our options to merge
>> OpenCMIS with Chemistry....
>
> I'm not sure if having two podlings implementing CMIS is a good idea.

I second that. Although I am, in principle, interested, I'd like to
know more about what would differentiate OpenCMIS from Chemistry, and
why is this duplication a good thing. From your proposal, I seem to
understand you are more focused on the CMIS client side, yet I would
like to understand a bit more what's missing from the client Chemistry
bit.

--=20
Gianugo

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


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


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