You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "Goetz, Paul" <pa...@sap.com> on 2009/12/09 18:21:21 UTC
[PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Hi,
we would like to propose a new incubator podling called OpenCMIS.
Please find below the plain-text version of the proposal.
Any feedback would be greatly appreciated.
Best regards,
Paul
------------------------
Apache OpenCMIS Proposal
Abstract
OpenCMIS will deliver a Java implementation of the OASIS CMIS specification.
Proposal
OpenCMIS provides a Java implementation of the OASIS CMIS specification. This includes a library to connect as a consumer to a CMIS repository, and a library to provide the CMIS protocol handlers on top of an existing repository. All the protocol bindings defined by the CMIS specification will be supported.
Background
The OASIS CMIS (Content Management Interoperability Services) specification is a standardization effort to enable interoperability of Enterprise Content Management (ECM) Systems. Like SQL became the standard for accessing database systems, CMIS aims to become a similar standard for accessing document management systems. CMIS was started by IBM, EMC and Microsoft. Most of the ECM vendors joined the OASIS Technical Committee (TC) for CMIS in the meanwhile as well.
The need for a common, open source CMIS library came up during the standardization work. David Caruana, David Ward, Florian Müller, Jens Hübel, Paul Goetz, Martin Hermes, and Stephan Klevenz from Alfresco, Open Text and SAP started an initiative and design outline to found this project. Code and some design ideas from an existing open source project owned by Florian Müller was an initial contribution to the project.
The aim is to build an object oriented Java implementation of CMIS that encapsulates the CMIS protocol bindings, mainly to support clients using CMIS. Focus of this project it to support the needs of an enterprise environment, that is reliability, performance, and monitoring.
Rationale
With CMIS being adopted by various ECM vendors, there is a strong need for repositories and applications dealing with content to support CMIS. As CMIS defines a domain model and protocol bindings, Java developers would have to implement the protocol bindings from scratch.
The CMIS specification focuses on the protocols, and is therefore service oriented. An object oriented API which encapsulates this services makes it easier for Java developers to use CMIS.
In turn, easy adoption of CMIS by Java applications should help the standard becoming widely adopted.
Initial Goals
* Implement the CMIS 1.0 protocol binding for SOAP
* Implement the CMIS 1.0 protocol binding for AtomPub
* Implement a library with an object oriented API to encapsulate the CMIS protocol bindings for consumers
Current Status
Meritocracy
The OpenCMIS contributors recognize the desirability of running the project as a meritocracy. We are eager to engage other members of the community and operate to the standard of meritocracy that Apache emphasizes; we believe this is the most effective method of growing our community and enabling widespread adoption.
Community
The OASIS Technical Committee (TC) is the community for the CMIS standard definition. Most of the TC members provide Java based ECM implementations, and are also interested to help building a CMIS library for Java.
Core Developers
The project was started by Florian Müller (Open Text) and Jens Hübel (Open Text). David Caruana (Alfresco) contributed, as well as Martin Hermes (SAP), Stephan Klevenz (SAP) and Paul Goetz (SAP).
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.
Known Risks
Orphaned Products
The contributors are working for companies relying on this library. There is minimal risk of this work becoming non-strategic. The contributors are confident, that a larger community will form within the project.
Inexperience with Open Source
The initial committers have varying degrees of experience with open source projects. There is limited access experience developing code with an open source development process. We do not, however, expect any difficulty in executing under normal meritocracy rules.
Homogenous Developers
The initial committers work for different companies (Open Text, Alfresco, and SAP). They work for different projects and knew each other only to their participation in the OASIS TC.
Reliance on Salaried Developers
Although the initial committers are salaried developers, OpenCMIS development was done both on work time and spare time. As the OpenCMIS library will be used in commercial products, some of the companies will dedicate work time to the project.
Relationships with Other Apache Products
OpenCMIS uses other Apache Products (Commons Codec, Commons Logging, CXF is planned). Maven is used as build infrastructure.
A Excessive Fascination with the Apache Brand
The developers of OpenCMIS could use other channels to generate publicity. We hope that the Apache brand helps to build a vendor independent, truly interoperable CMIS library. We would feel honored at getting the opportunity to join.
Documentation
[1] Information about the OASIS CMIS Technical Committee can be found at: [http://www.oasis-open.org/committees/cmis].
[2] The announcement of the public review for the CMIS 1.0 specification (containing the links to the specification) can be found at: [http://lists.oasis-open.org/archives/tc-announce/200910/msg00015.html]
Initial Source
The current implementation can be found on [http://svn.berlios.de/svnroot/repos/opencmis]
Source and Intellectual Property Submission Plan
* The initial source (see above)
* Additional source from Open Text developers (CLA in progress)
* Additional source from SAP developers (CCLA filed, CLA in progress)
* Additional source from Alfresco developers (CLA filed)
* The domain opencmis.org from Alfresco
External Dependencies
All the external dependencies of the initial codebase comply with Apache licensing policies:
* Apache Commons (Apache v2.0)
* Apache Maven (Apache v2.0)
* Sun JAXB and JAX-WS (CDDL v1.0, GPL v2)
* JUnit (CPL v1.0)
Cryptography
OpenCMIS does not implement or use cryptographic code.
Required Resources
Mailing lists
* opencmis-private (with moderated subscriptions)
* opencmis-dev
* opencmis-commits
* opencmis-user
Subversion Directory
* https://svn.apache.org/repos/asf/incubator/opencmis
Issue Tracing
* JIRA (OpenCMIS)
Other Resources
* Web Site: Confluence (OpenCMIS)
Initial Committers
* Florian Müller (Open Text)
* Jens Hübel (Open Text)
* David Caruana (Alfresco)
* David Ward (Alfresco)
* Martin Hermes (SAP)
* Stephan Klevenz (SAP)
* Paul Goetz (SAP)
Affiliations
The initial committers listed are employed by Open Text, Alfresco, and SAP. One objective of the incubator is to extend the community of contributors, we assume that future contributors will have other affiliations.
Sponsors
Champions
? tbd
Mentors
? Looking for mentors
Sponsoring Entity
The Incubator
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Stefane Fermigier <sf...@nuxeo.com>.
I find this proposal very strange.
Doesn't Chemistry already provide a client library ? What's the
problem with it ?
S.
On Dec 9, 2009, at 8:56 PM, Jukka Zitting wrote:
> Hi,
>
> For those who're not following general@incubator.
>
> BR,
>
> Jukka Zitting
>
>
> ---------- Forwarded message ----------
> From: Goetz, Paul <pa...@sap.com>
> Date: Wed, Dec 9, 2009 at 6:21 PM
> Subject: [PROPOSAL] OpenCMIS incubator for Content Mangement
> Interoperability Services (CMIS)
> To: "general@incubator.apache.org" <ge...@incubator.apache.org>
>
>
> Hi,
>
> we would like to propose a new incubator podling called OpenCMIS.
> Please find below the plain-text version of the proposal.
> Any feedback would be greatly appreciated.
>
> Best regards,
> Paul
>
>
> ------------------------
> Apache OpenCMIS Proposal
>
> Abstract
> OpenCMIS will deliver a Java implementation of the OASIS CMIS
> specification.
>
> Proposal
> OpenCMIS provides a Java implementation of the OASIS CMIS
> specification. This includes a library to connect as a consumer to a
> CMIS repository, and a library to provide the CMIS protocol handlers
> on top of an existing repository. All the protocol bindings defined by
> the CMIS specification will be supported.
>
> Background
> The OASIS CMIS (Content Management Interoperability Services)
> specification is a standardization effort to enable interoperability
> of Enterprise Content Management (ECM) Systems. Like SQL became the
> standard for accessing database systems, CMIS aims to become a similar
> standard for accessing document management systems. CMIS was started
> by IBM, EMC and Microsoft. Most of the ECM vendors joined the OASIS
> Technical Committee (TC) for CMIS in the meanwhile as well.
> The need for a common, open source CMIS library came up during the
> standardization work. David Caruana, David Ward, Florian Müller, Jens
> Hübel, Paul Goetz, Martin Hermes, and Stephan Klevenz from Alfresco,
> Open Text and SAP started an initiative and design outline to found
> this project. Code and some design ideas from an existing open source
> project owned by Florian Müller was an initial contribution to the
> project.
> The aim is to build an object oriented Java implementation of CMIS
> that encapsulates the CMIS protocol bindings, mainly to support
> clients using CMIS. Focus of this project it to support the needs of
> an enterprise environment, that is reliability, performance, and
> monitoring.
>
> Rationale
> With CMIS being adopted by various ECM vendors, there is a strong need
> for repositories and applications dealing with content to support
> CMIS. As CMIS defines a domain model and protocol bindings, Java
> developers would have to implement the protocol bindings from scratch.
> The CMIS specification focuses on the protocols, and is therefore
> service oriented. An object oriented API which encapsulates this
> services makes it easier for Java developers to use CMIS.
> In turn, easy adoption of CMIS by Java applications should help the
> standard becoming widely adopted.
>
> Initial Goals
> * Implement the CMIS 1.0 protocol binding for SOAP
> * Implement the CMIS 1.0 protocol binding for AtomPub
> * Implement a library with an object oriented API to encapsulate the
> CMIS protocol bindings for consumers
>
>
> Current Status
>
> Meritocracy
> The OpenCMIS contributors recognize the desirability of running the
> project as a meritocracy. We are eager to engage other members of the
> community and operate to the standard of meritocracy that Apache
> emphasizes; we believe this is the most effective method of growing
> our community and enabling widespread adoption.
>
> Community
> The OASIS Technical Committee (TC) is the community for the CMIS
> standard definition. Most of the TC members provide Java based ECM
> implementations, and are also interested to help building a CMIS
> library for Java.
>
> Core Developers
> The project was started by Florian Müller (Open Text) and Jens Hübel
> (Open Text). David Caruana (Alfresco) contributed, as well as Martin
> Hermes (SAP), Stephan Klevenz (SAP) and Paul Goetz (SAP).
>
> 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.
>
>
> Known Risks
>
> Orphaned Products
> The contributors are working for companies relying on this library.
> There is minimal risk of this work becoming non-strategic. The
> contributors are confident, that a larger community will form within
> the project.
>
> Inexperience with Open Source
> The initial committers have varying degrees of experience with open
> source projects. There is limited access experience developing code
> with an open source development process. We do not, however, expect
> any difficulty in executing under normal meritocracy rules.
>
> Homogenous Developers
> The initial committers work for different companies (Open Text,
> Alfresco, and SAP). They work for different projects and knew each
> other only to their participation in the OASIS TC.
>
> Reliance on Salaried Developers
> Although the initial committers are salaried developers, OpenCMIS
> development was done both on work time and spare time. As the OpenCMIS
> library will be used in commercial products, some of the companies
> will dedicate work time to the project.
>
> Relationships with Other Apache Products
> OpenCMIS uses other Apache Products (Commons Codec, Commons Logging,
> CXF is planned). Maven is used as build infrastructure.
>
> A Excessive Fascination with the Apache Brand
> The developers of OpenCMIS could use other channels to generate
> publicity. We hope that the Apache brand helps to build a vendor
> independent, truly interoperable CMIS library. We would feel honored
> at getting the opportunity to join.
>
>
> Documentation
> [1] Information about the OASIS CMIS Technical Committee can be found
> at: [http://www.oasis-open.org/committees/cmis].
> [2] The announcement of the public review for the CMIS 1.0
> specification (containing the links to the specification) can be found
> at: [http://lists.oasis-open.org/archives/tc-announce/200910/msg00015.html
> ]
>
>
> Initial Source
> The current implementation can be found on
> [http://svn.berlios.de/svnroot/repos/opencmis]
>
>
> Source and Intellectual Property Submission Plan
> * The initial source (see above)
> * Additional source from Open Text developers (CLA in progress)
> * Additional source from SAP developers (CCLA filed, CLA in progress)
> * Additional source from Alfresco developers (CLA filed)
> * The domain opencmis.org from Alfresco
>
> External Dependencies
> All the external dependencies of the initial codebase comply with
> Apache licensing policies:
> * Apache Commons (Apache v2.0)
> * Apache Maven (Apache v2.0)
> * Sun JAXB and JAX-WS (CDDL v1.0, GPL v2)
> * JUnit (CPL v1.0)
>
>
> Cryptography
> OpenCMIS does not implement or use cryptographic code.
>
>
> Required Resources
>
> Mailing lists
> * opencmis-private (with moderated subscriptions)
> * opencmis-dev
> * opencmis-commits
> * opencmis-user
>
> Subversion Directory
> * https://svn.apache.org/repos/asf/incubator/opencmis
>
> Issue Tracing
> * JIRA (OpenCMIS)
>
> Other Resources
> * Web Site: Confluence (OpenCMIS)
>
>
> Initial Committers
> * Florian Müller (Open Text)
> * Jens Hübel (Open Text)
> * David Caruana (Alfresco)
> * David Ward (Alfresco)
> * Martin Hermes (SAP)
> * Stephan Klevenz (SAP)
> * Paul Goetz (SAP)
>
>
> Affiliations
> The initial committers listed are employed by Open Text, Alfresco, and
> SAP. One objective of the incubator is to extend the community of
> contributors, we assume that future contributors will have other
> affiliations.
>
>
> Sponsors
>
> Champions
> ? tbd
>
> Mentors
> ? Looking for mentors
>
> Sponsoring Entity
> The Incubator
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
Fwd: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
For those who're not following general@incubator.
BR,
Jukka Zitting
---------- Forwarded message ----------
From: Goetz, Paul <pa...@sap.com>
Date: Wed, Dec 9, 2009 at 6:21 PM
Subject: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
To: "general@incubator.apache.org" <ge...@incubator.apache.org>
Hi,
we would like to propose a new incubator podling called OpenCMIS.
Please find below the plain-text version of the proposal.
Any feedback would be greatly appreciated.
Best regards,
Paul
------------------------
Apache OpenCMIS Proposal
Abstract
OpenCMIS will deliver a Java implementation of the OASIS CMIS specification.
Proposal
OpenCMIS provides a Java implementation of the OASIS CMIS
specification. This includes a library to connect as a consumer to a
CMIS repository, and a library to provide the CMIS protocol handlers
on top of an existing repository. All the protocol bindings defined by
the CMIS specification will be supported.
Background
The OASIS CMIS (Content Management Interoperability Services)
specification is a standardization effort to enable interoperability
of Enterprise Content Management (ECM) Systems. Like SQL became the
standard for accessing database systems, CMIS aims to become a similar
standard for accessing document management systems. CMIS was started
by IBM, EMC and Microsoft. Most of the ECM vendors joined the OASIS
Technical Committee (TC) for CMIS in the meanwhile as well.
The need for a common, open source CMIS library came up during the
standardization work. David Caruana, David Ward, Florian Müller, Jens
Hübel, Paul Goetz, Martin Hermes, and Stephan Klevenz from Alfresco,
Open Text and SAP started an initiative and design outline to found
this project. Code and some design ideas from an existing open source
project owned by Florian Müller was an initial contribution to the
project.
The aim is to build an object oriented Java implementation of CMIS
that encapsulates the CMIS protocol bindings, mainly to support
clients using CMIS. Focus of this project it to support the needs of
an enterprise environment, that is reliability, performance, and
monitoring.
Rationale
With CMIS being adopted by various ECM vendors, there is a strong need
for repositories and applications dealing with content to support
CMIS. As CMIS defines a domain model and protocol bindings, Java
developers would have to implement the protocol bindings from scratch.
The CMIS specification focuses on the protocols, and is therefore
service oriented. An object oriented API which encapsulates this
services makes it easier for Java developers to use CMIS.
In turn, easy adoption of CMIS by Java applications should help the
standard becoming widely adopted.
Initial Goals
* Implement the CMIS 1.0 protocol binding for SOAP
* Implement the CMIS 1.0 protocol binding for AtomPub
* Implement a library with an object oriented API to encapsulate the
CMIS protocol bindings for consumers
Current Status
Meritocracy
The OpenCMIS contributors recognize the desirability of running the
project as a meritocracy. We are eager to engage other members of the
community and operate to the standard of meritocracy that Apache
emphasizes; we believe this is the most effective method of growing
our community and enabling widespread adoption.
Community
The OASIS Technical Committee (TC) is the community for the CMIS
standard definition. Most of the TC members provide Java based ECM
implementations, and are also interested to help building a CMIS
library for Java.
Core Developers
The project was started by Florian Müller (Open Text) and Jens Hübel
(Open Text). David Caruana (Alfresco) contributed, as well as Martin
Hermes (SAP), Stephan Klevenz (SAP) and Paul Goetz (SAP).
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.
Known Risks
Orphaned Products
The contributors are working for companies relying on this library.
There is minimal risk of this work becoming non-strategic. The
contributors are confident, that a larger community will form within
the project.
Inexperience with Open Source
The initial committers have varying degrees of experience with open
source projects. There is limited access experience developing code
with an open source development process. We do not, however, expect
any difficulty in executing under normal meritocracy rules.
Homogenous Developers
The initial committers work for different companies (Open Text,
Alfresco, and SAP). They work for different projects and knew each
other only to their participation in the OASIS TC.
Reliance on Salaried Developers
Although the initial committers are salaried developers, OpenCMIS
development was done both on work time and spare time. As the OpenCMIS
library will be used in commercial products, some of the companies
will dedicate work time to the project.
Relationships with Other Apache Products
OpenCMIS uses other Apache Products (Commons Codec, Commons Logging,
CXF is planned). Maven is used as build infrastructure.
A Excessive Fascination with the Apache Brand
The developers of OpenCMIS could use other channels to generate
publicity. We hope that the Apache brand helps to build a vendor
independent, truly interoperable CMIS library. We would feel honored
at getting the opportunity to join.
Documentation
[1] Information about the OASIS CMIS Technical Committee can be found
at: [http://www.oasis-open.org/committees/cmis].
[2] The announcement of the public review for the CMIS 1.0
specification (containing the links to the specification) can be found
at: [http://lists.oasis-open.org/archives/tc-announce/200910/msg00015.html]
Initial Source
The current implementation can be found on
[http://svn.berlios.de/svnroot/repos/opencmis]
Source and Intellectual Property Submission Plan
* The initial source (see above)
* Additional source from Open Text developers (CLA in progress)
* Additional source from SAP developers (CCLA filed, CLA in progress)
* Additional source from Alfresco developers (CLA filed)
* The domain opencmis.org from Alfresco
External Dependencies
All the external dependencies of the initial codebase comply with
Apache licensing policies:
* Apache Commons (Apache v2.0)
* Apache Maven (Apache v2.0)
* Sun JAXB and JAX-WS (CDDL v1.0, GPL v2)
* JUnit (CPL v1.0)
Cryptography
OpenCMIS does not implement or use cryptographic code.
Required Resources
Mailing lists
* opencmis-private (with moderated subscriptions)
* opencmis-dev
* opencmis-commits
* opencmis-user
Subversion Directory
* https://svn.apache.org/repos/asf/incubator/opencmis
Issue Tracing
* JIRA (OpenCMIS)
Other Resources
* Web Site: Confluence (OpenCMIS)
Initial Committers
* Florian Müller (Open Text)
* Jens Hübel (Open Text)
* David Caruana (Alfresco)
* David Ward (Alfresco)
* Martin Hermes (SAP)
* Stephan Klevenz (SAP)
* Paul Goetz (SAP)
Affiliations
The initial committers listed are employed by Open Text, Alfresco, and
SAP. One objective of the incubator is to extend the community of
contributors, we assume that future contributors will have other
affiliations.
Sponsors
Champions
? tbd
Mentors
? Looking for mentors
Sponsoring Entity
The Incubator
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Florent Guillaume <fg...@nuxeo.com>.
On Sun, Dec 20, 2009 at 2:02 PM, Goetz, Paul <pa...@sap.com> wrote:
> Jukka Zitting wrote:
>> Have you had a chance to digest all the feedback?
>
> Well, we're still digesting :o)
> Florian started bit of a discussion on the Chemistry mailing list, but there was not too much of a feedback - due to vacation. I guess, we will need some more time to get into the technical discussion. So we're still working on that one on the Chemistry mailing list.
Note that these discussions are explanations of each other's code and
architectures, but that they won't lead to immediate concrete changes
because that's not their goal for now — for me their goal is to
convince you that we're not that far from each other.
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
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by "Goetz, Paul" <pa...@sap.com>.
Hi,
first, thanks for all your feedback.
Jukka Zitting wrote:
> Have you had a chance to digest all the feedback?
Well, we're still digesting :o)
Florian started bit of a discussion on the Chemistry mailing list, but there was not too much of a feedback - due to vacation. I guess, we will need some more time to get into the technical discussion. So we're still working on that one on the Chemistry mailing list.
Jukka Zitting wrote:
> The way I see it, the options for going forward with this proposal are:
> 1) Include OpenCMIS in the Chemistry project as a parallel codebase.
> 2) Incubate OpenCMIS as a separate project.
> I'd personally prefer option 1 as it requires less up-front setup and
> avoids extra barriers between the communities, but I'd be happy to
> support also option 2 if the OpenCMIS community prefers that.
Thanks for offering your support.
We (the OpenCMIS team) will get back to you next week to figure out how these two options could look like in more detail, and how we could go on from an organizational perspective.
I hope that we could continue after Christmas then on the Incubator's general mailing list.
Best regards,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Dec 9, 2009 at 6:21 PM, Goetz, Paul <pa...@sap.com> wrote:
> we would like to propose a new incubator podling called OpenCMIS.
Have you had a chance to digest all the feedback?
The way I see it, the options for going forward with this proposal are:
1) Include OpenCMIS in the Chemistry project as a parallel codebase.
2) Incubate OpenCMIS as a separate project.
I'd personally prefer option 1 as it requires less up-front setup and
avoids extra barriers between the communities, but I'd be happy to
support also option 2 if the OpenCMIS community prefers that. Note
that we could also get started with option 1 and move on to option 2
if coexistence within a single project doesn't work out.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Gianugo Rabellino <gi...@gmail.com>.
Florian,
On Thu, Dec 10, 2009 at 10:03 AM, Florian Müller <fm...@opentext.com> wrote:
> Hi,
>
> I can talk a bit about the OpenCMIS architecture. That might help to distinguish it from Chemistry.
<snip/>
> I hope that helps.
It does, thanks for sharing. However, it would help a lot more as a
foundation for a discussion with a more knowledgeable community such
as the Chemistry one.
Thanks,
--
Gianugo Rabellino
Sourcesense, making sense of Open Source: http://www.sourcesense.com
(blogging at http://www.rabellino.it/blog/)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Florian Müller <fm...@opentext.com>.
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]
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]
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
<bd...@apache.org> wrote:
> On Wed, Dec 9, 2009 at 6:21 PM, Goetz, Paul <pa...@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.
--
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
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Paul,
On Thu, Dec 10, 2009 at 9:19 AM, Goetz, Paul <pa...@sap.com> wrote:
> ...we discussed that with Florent Guillaume (from Chemistry) already....
Ok - although Florent is AFAIK very much involved in Chemistry, in my
Apache book that doesn't count as discussing with the Chemistry
project. What bugged me when seeing your proposal appear here is that
(AFAIK - happy to be corrected if that's wrong) no discussions haven
happened on the Chemistry mailing lists about this.
> ...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....
Ok, that might make sense.
> ...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....
Of course, but having two podlings working on a spec that's still in
flux feels like a waste of energy, as opposed to people collaborating
in the same podling.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by David Nuescheler <da...@gmail.com>.
hi all,
On Thu, Dec 10, 2009 at 12:09 PM, Gianugo Rabellino <gi...@gmail.com> wrote:
> None of the above issues is a blocker, but the sum of the parts
> doesn't give me exactly a warm, fuzzy feeling. I would appreciate the
> proponents having a discussion with Chemistry first. If OpenCMIS,
> however, prefers to skip that step and manages to score champions and
> mentors, I won't stand in the way.
same here.
thanks gianugo for phrasing things so eloquently.
i can just tell you that from my experience with the chemistry community
every input from the group of initial committers would be very welcome.
be architectural input or code, you are all very welcome on the list.
regards,
david
.ps: thanks to florent for pointing out that chemistry has no jcr coupling ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Michael Wechner <mi...@wyona.com>.
Gianugo Rabellino wrote:
> On Thu, Dec 10, 2009 at 11:17 AM, Michael Wechner
> <mi...@wyona.com> wrote:
>
>> Bertrand Delacretaz wrote:
>>
>>> As Gianugo says, the Chemistry folks are certainly the best people to
>>> judge (together with you guys of course) whether your ideas can be
>>> incorporated in Chemistry, or are better off in a separate project.
>>>
>>> The Incubator's position is very probably that it's fine to have
>>> different projects working on similar things, but in general we're all
>>> for strong communities, and if you guys can join forces with Chemistry
>>> from the start that's probably a better way to build a strong
>>> community.
>>>
>>>
>> well, let's be honest: Merging communities can be a very difficult thing
>> (from both sides)
>>
>> I don't think it's a problem to have two CMIS projects. I think the
>> important thing is that
>> each project is able to build a "healthy" community around code of great
>> quality and that
>> the communications/processes are transparent.
>>
>> I understand that from the outside it looks odd to have two or even several
>> projects of the same topic, but evolution is variation (with some
>> balance though ;-)
>>
>
> Michael,
>
> don't get me wrong, I have no objections in principle for having two
> or more competing projects. It's just that my bar is higher in this
> case, as:
>
> - we are talking about two podlings, which IIRC is a first;
>
> - they both aim to implement a moving target;
>
> - the prospective OpenCMIS community started seemingly with the wrong
> foot by not addressing the Chemistry community first and looking for
> potential mutual engagements, despite being in the best possible
> situation, such as having a committer in common;
>
> - when asked to try and contact Chemistry, Paul chalked it up as time consuming;
>
> - the proposal came in with no candidate champion or mentors.
>
> None of the above issues is a blocker, but the sum of the parts
> doesn't give me exactly a warm, fuzzy feeling. I would appreciate the
> proponents having a discussion with Chemistry first. If OpenCMIS,
> however, prefers to skip that step and manages to score champions and
> mentors, I won't stand in the way.
>
sounds reasonable to me :-)
Cheers
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Gianugo Rabellino <gi...@gmail.com>.
On Thu, Dec 10, 2009 at 11:17 AM, Michael Wechner
<mi...@wyona.com> wrote:
> Bertrand Delacretaz wrote:
>>
>> As Gianugo says, the Chemistry folks are certainly the best people to
>> judge (together with you guys of course) whether your ideas can be
>> incorporated in Chemistry, or are better off in a separate project.
>>
>> The Incubator's position is very probably that it's fine to have
>> different projects working on similar things, but in general we're all
>> for strong communities, and if you guys can join forces with Chemistry
>> from the start that's probably a better way to build a strong
>> community.
>>
>
> well, let's be honest: Merging communities can be a very difficult thing
> (from both sides)
>
> I don't think it's a problem to have two CMIS projects. I think the
> important thing is that
> each project is able to build a "healthy" community around code of great
> quality and that
> the communications/processes are transparent.
>
> I understand that from the outside it looks odd to have two or even several
> projects of the same topic, but evolution is variation (with some
> balance though ;-)
Michael,
don't get me wrong, I have no objections in principle for having two
or more competing projects. It's just that my bar is higher in this
case, as:
- we are talking about two podlings, which IIRC is a first;
- they both aim to implement a moving target;
- the prospective OpenCMIS community started seemingly with the wrong
foot by not addressing the Chemistry community first and looking for
potential mutual engagements, despite being in the best possible
situation, such as having a committer in common;
- when asked to try and contact Chemistry, Paul chalked it up as time consuming;
- the proposal came in with no candidate champion or mentors.
None of the above issues is a blocker, but the sum of the parts
doesn't give me exactly a warm, fuzzy feeling. I would appreciate the
proponents having a discussion with Chemistry first. If OpenCMIS,
however, prefers to skip that step and manages to score champions and
mentors, I won't stand in the way.
--
Gianugo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Michael Wechner <mi...@wyona.com>.
Bertrand Delacretaz wrote:
>
> As Gianugo says, the Chemistry folks are certainly the best people to
> judge (together with you guys of course) whether your ideas can be
> incorporated in Chemistry, or are better off in a separate project.
>
> The Incubator's position is very probably that it's fine to have
> different projects working on similar things, but in general we're all
> for strong communities, and if you guys can join forces with Chemistry
> from the start that's probably a better way to build a strong
> community.
>
well, let's be honest: Merging communities can be a very difficult thing
(from both sides)
I don't think it's a problem to have two CMIS projects. I think the
important thing is that
each project is able to build a "healthy" community around code of great
quality and that
the communications/processes are transparent.
I understand that from the outside it looks odd to have two or even
several projects of the same topic, but evolution is variation (with some
balance though ;-)
Cheers
Michael
> -Bertrand
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Dec 10, 2009 at 10:47 AM, Goetz, Paul <pa...@sap.com> wrote:
>...well, sorry that the discussion did not happen on the Chemistry mailing list.
>
> But for those being employees needing a legal clearance from their employer, before they
> can contribute or mail to a mailing list, it is difficult to do that in an early stage...
> That's why we discussed that with Florent - and I did assume that he was discussing that
> with the Chemistry project....
Nothing bad in discussing things with Florent of course, but again
private discussions are not relevant to project-level decisions at
Apache. If it didn't happen on a public mailing list, that doesn't
count...
>
> ...We have a working code base already - discussing the modus operandi and a potential merge
> with Chemistry seems to be time consuming to me (compared to doing a review once the
> entire OpenCMIS code is available and stabilized). Wouldn't it be worth to give it a try?...
IMHO, not until we hear the Chemistry community's opinion.
>
> Gianugo Rabellino wrote:
>> 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 would also like to see what the community as a whole thinks about it...
As Gianugo says, the Chemistry folks are certainly the best people to
judge (together with you guys of course) whether your ideas can be
incorporated in Chemistry, or are better off in a separate project.
The Incubator's position is very probably that it's fine to have
different projects working on similar things, but in general we're all
for strong communities, and if you guys can join forces with Chemistry
from the start that's probably a better way to build a strong
community.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by "Goetz, Paul" <pa...@sap.com>.
Hi Gianugo,
you wrote
> I understand and sympathize, but if this is the kind of issues you are
> facing, I would suggest that you have much bigger problems to solve
> than an Open Source project. Actually, your statement is extremely
> worrisome, as you should be aware that in Apache you have to act as an
> individual: it's fine that you bring your company agenda to the table,
> but it's also important that you are able to decide based on pure
> technical merit and exercise your judgement as an individual. If you
> don't feel that's the case - and indeed I can smell some issues here -
> maybe the ASF is not the right place for you and you will find a more
> corporate-friendly environment somewhere else (Eclipse comes to mind).
Sorry again, but all I am saying is that I had no clearance until December.
That's why in November (when discussing with Florent) I couldn't use the mailing list.
Now, this is obviously no longer the case. So there are no issues from my side regarding this...
Best regards,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Gianugo Rabellino <gi...@gmail.com>.
On Thu, Dec 10, 2009 at 10:47 AM, Goetz, Paul <pa...@sap.com> wrote:
> Hi,
>
> well, sorry that the discussion did not happen on the Chemistry mailing list.
>
> But for those being employees needing a legal clearance from their employer, before they can contribute or mail to a mailing list, it is difficult to do that in an early stage...
I understand and sympathize, but if this is the kind of issues you are
facing, I would suggest that you have much bigger problems to solve
than an Open Source project. Actually, your statement is extremely
worrisome, as you should be aware that in Apache you have to act as an
individual: it's fine that you bring your company agenda to the table,
but it's also important that you are able to decide based on pure
technical merit and exercise your judgement as an individual. If you
don't feel that's the case - and indeed I can smell some issues here -
maybe the ASF is not the right place for you and you will find a more
corporate-friendly environment somewhere else (Eclipse comes to mind).
> We have a working code base already - discussing the modus operandi and a potential merge with Chemistry seems to be time consuming to me (compared to doing a review once the entire OpenCMIS code is available and stabilized). Wouldn't it be worth to give it a try?
I'm not going to formally stop you, but I would say that "giving it a
try" just for the sake of it is not quite the right way to start. You
have to realize that incubating a project requires time and dedication
from the Incubator PMC as a whole, from your mentors and from the
champion: it's no small feat by any stretch of imagination. Letting
you start incubating without properly scrutinizing the issue of how
you might relate with another podling just because your employer makes
it difficult to have an open discussion to a mailing list doesn't
sound a single bit right to me.
--
Gianugo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by "Goetz, Paul" <pa...@sap.com>.
Hi,
well, sorry that the discussion did not happen on the Chemistry mailing list.
But for those being employees needing a legal clearance from their employer, before they can contribute or mail to a mailing list, it is difficult to do that in an early stage...
That's why we discussed that with Florent - and I did assume that he was discussing that with the Chemistry project.
We have a working code base already - discussing the modus operandi and a potential merge with Chemistry seems to be time consuming to me (compared to doing a review once the entire OpenCMIS code is available and stabilized). Wouldn't it be worth to give it a try?
Gianugo Rabellino wrote:
> 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 would also like to see what the community as a whole thinks about it.
Best regards,
Paul
-----Original Message-----
From: Felix Meschberger [mailto:fmeschbe@gmail.com]
Sent: Donnerstag, 10. Dezember 2009 10:00
To: general@incubator.apache.org
Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Hi,
Gianugo Rabellino schrieb:
> ... snip ...
> 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.
I share Gianugo's and Bertrand's concerns. And as a mentor to the
Chemistry poddling, I am even somewhat more concerned....
As such, I would welcome such discussion very much to take place and to
sort out the issues.
Regards
Felix
>
>> 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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Gianugo Rabellino schrieb:
> ... snip ...
> 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.
I share Gianugo's and Bertrand's concerns. And as a mentor to the
Chemistry poddling, I am even somewhat more concerned....
As such, I would welcome such discussion very much to take place and to
sort out the issues.
Regards
Felix
>
>> 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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Gianugo Rabellino <gi...@gmail.com>.
Paul, thanks for your reply. Some quick comments:
On Thu, Dec 10, 2009 at 9:19 AM, Goetz, Paul <pa...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by "Goetz, Paul" <pa...@sap.com>.
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]
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
<bd...@apache.org> wrote:
> On Wed, Dec 9, 2009 at 6:21 PM, Goetz, Paul <pa...@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.
--
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
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Gianugo Rabellino <gi...@gmail.com>.
On Wed, Dec 9, 2009 at 6:33 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Wed, Dec 9, 2009 at 6:21 PM, Goetz, Paul <pa...@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.
--
Gianugo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'm not sure if having two podlings implementing CMIS is a good idea.
The Incubator is not really in the business of pre-selecting winners. If there are two communities that want to incubate, those are two separate items. If there is a reason to see if they can merge, I am all for it. Merging can mean more critical mass and a more diverse community. But there is a difference between encouraging and facilitating a merger, and forcing one or choosing a "winner".
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Dec 9, 2009 at 6:21 PM, Goetz, Paul <pa...@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.
Has this proposal been discussed with the Chemistry podling?
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Leo Simons <ma...@leosimons.com>.
Heya OpenCMIS folks,
Since it looks like you aren't currently supported by a champion or
mentor [1], I thought I'd fill in a small part and inject some warm
fuzzies...
*Thanks* for open sourcing your project and *thanks* for considering
doing it at apache. Its always a lot of effort to go through this kind
of public vetting and I'm sure the wider CMIS community will somehow
benefit from you taking the time.
Though it may look like you're not really receiving the warm welcome you
perhaps expected, this kind of discussion is quite normal when people
(engineery types especially!) are excited about a topic...in some ways
the only warm welcome we do is the "hot" welcome :)
So even if it doesn't feel that way, having this boatload of discussion
is actually sort of good news -- you have sparked lots of interest and
people are looking carefully at your proposal, Jukka's even looking at
all the code in detail, that doesn't always happen ;)
It looks like you're doing a good job keeping it cool and answering
questions. I'm sure there's a couple of days more work ahead to sort out
what looks like a pretty complex discussion about the relationship
between OpenCMIS and Chemistry. Keep at it!
cheers,
Leo
[1] no, you really don't want me as a mentor [2], so don't ask :)
[2] because I would offer you an opinion or two about CMIS and it'd all
end in tears...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org