[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.
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Wed, Dec 9, 2009 at 6:21 PM, Goetz, Paul 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Wed, Dec 9, 2009 at 6:33 PM, Bertrand Delacretaz wrote: > On Wed, Dec 9, 2009 at 6:21 PM, Goetz, Paul 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
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:gian...@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 wrote: > On Wed, Dec 9, 2009 at 6:21 PM, Goetz, Paul 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Paul, thanks for your reply. Some quick comments: On Thu, Dec 10, 2009 at 9:19 AM, Goetz, Paul 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
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Hi Paul, On Thu, Dec 10, 2009 at 9:19 AM, Goetz, Paul 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
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.go...@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:gian...@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 wrote: > On Wed, Dec 9, 2009 at 6:21 PM, Goetz, Paul 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 dupl
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
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:fmesc...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Florian, On Thu, Dec 10, 2009 at 10:03 AM, Florian Müller wrote: > Hi, > > I can talk a bit about the OpenCMIS architecture. That might help to > distinguish it from Chemistry. > 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Thu, Dec 10, 2009 at 10:47 AM, Goetz, Paul 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Hi, On Thu, Dec 10, 2009 at 10:47 AM, Goetz, Paul 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Thu, Dec 10, 2009 at 11:17 AM, Michael Wechner 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
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
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Thu, Dec 10, 2009 at 4:00 PM, Florent Guillaume wrote: > (or the fact that the code has not be released in any public manner yet) Apologies, the code *is* released. Just not the discussions around its design and its future. 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
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Gianugo Rabellino wrote: On Thu, Dec 10, 2009 at 11:17 AM, Michael Wechner 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
hi all, On Thu, Dec 10, 2009 at 12:09 PM, Gianugo Rabellino 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Hi Stefane, I'm not sure I get your point. If OpenCMIS would become a top level subproject within Chemistry (which is what Florent suggested) then those two topics would still remain. It would be even worse: Chemistry would then have two client APIs which would be really confusing. The only way to overcome this is to merge the OpenCMIS code into the Chemistry code base. But the technical approaches of the projects are so different that this might not work - at least not in the short term. Or is your message that you don't want OpenCMIS code at all on Apache? Florian -Original Message- From: Stefane Fermigier [mailto:s...@nuxeo.com] Sent: Friday, December 11, 2009 3:52 PM To: chemistry-...@incubator.apache.org Cc: Incubator-General Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS) Same for me (if I understand your opinion correctly): we shouldn't have OpenCMIS competing with a subproject of Chemistry, because it will have a negative impact both internally (on project developers) and externally (on project customers): 1. Internally: duplication of effort, instead of focussing on providing the best possible API. 2. Externally: blurred message, two different API / models to learn. S. On Dec 11, 2009, at 2:35 PM, Ugo Cei wrote: > > On Dec 10, 2009, at 4:00 PM, Florent Guillaume wrote: > >> 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. > > > Here's my +1 from the peanut gallery. I personally don't find the > idea of incubating OpenCMIS appealing at all. > > Ugo > > -- > Ugo Cei > Sourcesense - making sense of Open Source: http://www.sourcesense.com > -- 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Dec 10, 2009, at 4:00 PM, Florent Guillaume wrote: > 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. Here's my +1 from the peanut gallery. I personally don't find the idea of incubating OpenCMIS appealing at all. Ugo -- Ugo Cei Sourcesense - making sense of Open Source: http://www.sourcesense.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Same for me (if I understand your opinion correctly): we shouldn't have OpenCMIS competing with a subproject of Chemistry, because it will have a negative impact both internally (on project developers) and externally (on project customers): 1. Internally: duplication of effort, instead of focussing on providing the best possible API. 2. Externally: blurred message, two different API / models to learn. S. On Dec 11, 2009, at 2:35 PM, Ugo Cei wrote: On Dec 10, 2009, at 4:00 PM, Florent Guillaume wrote: 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. Here's my +1 from the peanut gallery. I personally don't find the idea of incubating OpenCMIS appealing at all. Ugo -- Ugo Cei Sourcesense - making sense of Open Source: http://www.sourcesense.com -- 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Dec 11, 2009, at 4:44 PM, Florian Müller wrote: Hi Stefane, I'm not sure I get your point. If OpenCMIS would become a top level subproject within Chemistry (which is what Florent suggested) then those two topics would still remain. It would be even worse: Chemistry would then have two client APIs which would be really confusing. The only way to overcome this is to merge the OpenCMIS code into the Chemistry code base. But the technical approaches of the projects are so different that this might not work - at least not in the short term. Or is your message that you don't want OpenCMIS code at all on Apache? My message is that I don't think we should have two different, competing CMIS client APIs in Apache, specially if they start being developed at the roughly the same time. S. -- 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Hi, On Fri, Dec 11, 2009 at 4:44 PM, Florian Müller wrote: > The only way to overcome this is to merge the OpenCMIS code into the > Chemistry code base. But the technical approaches of the projects are so > different that this might not work - at least not in the short term. I compared opencmis-provider-api to chemistry-api. While there are differences in design (granularity of interfaces, type safety, etc.), the fundamental architecture is the same for both projects. This is as expected as they both map the same standard to Java. Are there some specific reasons why one design is superior to the other? The only major difference I could quickly spot is the ExtensionsData structure that OpenCMIS seems to include in almost all method signatures. Other than that it looks like it would be fairly straightforward to map from one API to another. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Hi Chemistry, I understand the concerns you might have and the confusion we have caused. But please do not forget that Open in Open Source has a meaning. So I am not sure that all the comments I read here are in accordance with the idea of it. So before you just say "No" please think about - If alternative solutions, competitive development is by itself a bad thing - alternatives means that a customer can choose - alternatives allow us in an open environment to pick the best from what you have and what we have - implemented alternatives are the best way to judge what the best solution is (for a certain task) All I am saying is just be open Jens - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Fri, Dec 11, 2009 at 5:24 PM, Jukka Zitting wrote: > I compared opencmis-provider-api to chemistry-api. While there are > differences in design (granularity of interfaces, type safety, etc.), > the fundamental architecture is the same for both projects. This is as > expected as they both map the same standard to Java. > > Are there some specific reasons why one design is superior to the > other? The only major difference I could quickly spot is the > ExtensionsData structure that OpenCMIS seems to include in almost all > method signatures. Other than that it looks like it would be fairly > straightforward to map from one API to another. I haven't had time to look at the OpenCMIS code yet. If there are useful use cases for adding ExtensionsData then there's no question that this'll get added to Chemistry. Note that the SOAP bindings have this anyway, since this is required by the XSDs. 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
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Dec 11, 2009, at 5:28 PM, Jens Hübel wrote: Hi Chemistry, I understand the concerns you might have and the confusion we have caused. But please do not forget that Open in Open Source has a meaning. So I am not sure that all the comments I read here are in accordance with the idea of it. I don't know what's *your* idea of open source, but I stand by my comments and I've been practicing and advocating open source since 1991. More seriously, let's not attack each other's conception of open source, and focus on the question at hand. Everyone, member of the open source community or not, is free to start a new implementation of an existing piece of software or library. This is a good thing when the existing software is in maintenance mode and not evolving anymore, or so crufty that a new design is needed, etc. But when we are speaking of two young projects, under the umbrella of the same organisation, I think this is very wrong. S. -- 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Fri, Dec 11, 2009 at 5:48 PM, Stefane Fermigier wrote:
> ...More seriously, let's not attack each other's conception of open source,
> and
> focus on the question at hand
+1
>
> ...Everyone, member of the open source community or not, is free to start a
> new
> implementation of an existing piece of software or library. This is a good
> thing when the existing software is in maintenance mode and not evolving
> anymore, or so crufty that a new design is needed, etc. But when we are
> speaking of two young projects, under the umbrella of the same organisation,
> I think this is very wrong
I'm not involved in Chemistry so speaking from my overall Apache (and
incubator, as a serial mentor of sorts) point of view.
I wouldn't make that as strong ("very wrong") as Stéfane puts it -
having competing projects can be good, but in this case, with a young
technology like CMIS it's probably much better to join forces as
opposed to competing.
Apache is about building communities, and if a strong one can be built
as opposed to two weaker ones that's a big plus.
I like Florent's idea to bring the OpenCMIS code in Chemistry in a
separate tree at first, and factor out the common parts. Having two
parallel implementations in the same project is somewhat unusuall, but
not unheard of - and certainly not a problem for such bleeding edge
stuff, IMHO.
-Bertrand
(full disclosure: I work for Day Software and some of my colleagues
are involved in Chemistry)
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Hi Jukka, In the end the APIs should be somewhat similar since they are implementing the same spec. But you are actually comparing two different levels of APIs. The opencmis-provider-api handles simple immutable data objects while chemistry-api follows an object-oriented approach. As far as I know Chemistry has nothing comparable to the opencmis-provider-api. The opencmis-client-api would be the right level to look at but the code of this API is not in SVN yet. We will make available on Monday. The APIs are not the main reason why I think that Chemistry and OpenCMIS are different. (I would like to avoid the word "superior". I never used that in this context. Both projects came from a different background that's why they are different.) Chemistry uses Abdera to communicate with the server while OpenCMIS is based on JAX-B and some CMIS specific XML coding. There is a lot of code sharing between the AtomPub and the Web Services binding. (I couldn't find a Web Services client in Chemistry. So I can't comment on that.) OpenCMIS has a caching infrastructure that is specific to CMIS and how OpenCMIS work. There is nothing like that in Chemistry. The overall architecture and principals below the API are very, very different. Bringing both together would require philosophy changes on both sides. I'm not saying that this isn't possible, but it's a lengthy process. We derived our design from a lot of prototypes and applications that we have built over the past 20 months. Some code fragments and concepts are actually pretty old now. We had a lot of it in one shape or another when Chemistry started. That's why Chemistry was never an option for us. The code bases of Chemistry and OpenCMIS have been developed at the same time taking different routes. Chemistry did that in the public, most of OpenCMIS was created behind closed doors. Here we are with a working code base that we cannot give up and that we will maintain in the future for obvious reasons. Our idea was to make it Open Source and let others benefit from our work. Apache seemed to be the right place - at least three days ago. It was never meant to be an attack against Chemistry. Florian -Original Message- From: Jukka Zitting [mailto:jukka.zitt...@gmail.com] Sent: Friday, December 11, 2009 5:24 PM To: chemistry-...@incubator.apache.org Cc: Incubator-General Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS) Hi, On Fri, Dec 11, 2009 at 4:44 PM, Florian Müller wrote: > The only way to overcome this is to merge the OpenCMIS code into the > Chemistry code base. But the technical approaches of the projects are so > different that this might not work - at least not in the short term. I compared opencmis-provider-api to chemistry-api. While there are differences in design (granularity of interfaces, type safety, etc.), the fundamental architecture is the same for both projects. This is as expected as they both map the same standard to Java. Are there some specific reasons why one design is superior to the other? The only major difference I could quickly spot is the ExtensionsData structure that OpenCMIS seems to include in almost all method signatures. Other than that it looks like it would be fairly straightforward to map from one API to another. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Fri, Dec 11, 2009 at 7:10 PM, Florian Müller wrote: > But you are actually comparing two different levels of APIs. The > opencmis-provider-api handles simple immutable data objects while > chemistry-api follows an object-oriented approach. As far as I know Chemistry > has nothing comparable to the opencmis-provider-api. The Chemistry SPI class provides a data-transfer-object-based API that is similar to opencmis-provider-api although implemented very differently. > The opencmis-client-api would be the right level to look at but the code of > this API is not in SVN yet. We will make available on Monday. > The APIs are not the main reason why I think that Chemistry and OpenCMIS are > different. (I would like to avoid the word "superior". I never used that in > this context. Both projects came from a different background that's why they > are different.) > Chemistry uses Abdera to communicate with the server while OpenCMIS is based > on JAX-B and some CMIS specific XML coding. Actually no, the Chemistry client side doesn't use Abdera, it uses an ad-hoc StAX-based serialization. Currently the server side still uses Abdera but I'd like to make this go away and use StAX as well, as Abdera is very heavy and costly (and not well extensible). >There is a lot of code sharing between the AtomPub and the Web Services >binding. (I couldn't find a Web Services client in Chemistry. So I can't >comment on that.) Indeed in Chemistry the AtomPub client code doesn't use JAX-B based serialization so doesn't share code with SOAP. JAX-B makes for a lot of intermediate objects whose structure depends on the XML you want to generate, which is fine for SOAP but doesn't seem right to me when designing an API from scratch. I wanted the APIs to be as Java-ish as possible and hide the underlying XML structural choices as much as possible. >OpenCMIS has a caching infrastructure that is specific to CMIS and how >OpenCMIS work. There is nothing like that in Chemistry. Yes Chemistry has no caching yet, this will be added later at the level of the high-level API implementation. For me it's not the role of the SPI to do caching. Florent > The overall architecture and principals below the API are very, very > different. Bringing both together would require philosophy changes on both > sides. I'm not saying that this isn't possible, but it's a lengthy process. > > We derived our design from a lot of prototypes and applications that we have > built over the past 20 months. Some code fragments and concepts are actually > pretty old now. We had a lot of it in one shape or another when Chemistry > started. That's why Chemistry was never an option for us. The code bases of > Chemistry and OpenCMIS have been developed at the same time taking different > routes. Chemistry did that in the public, most of OpenCMIS was created behind > closed doors. > > Here we are with a working code base that we cannot give up and that we will > maintain in the future for obvious reasons. Our idea was to make it Open > Source and let others benefit from our work. Apache seemed to be the right > place - at least three days ago. It was never meant to be an attack against > Chemistry. > > -- 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
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Dec 11, 2009, at 7:10 PM, Florian Müller wrote: Chemistry uses Abdera to communicate with the server while OpenCMIS is based on JAX-B and some CMIS specific XML coding. I've been personally asking myself recently wether it would be feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO it's something that should be discussed together and not a division line for us. There is a lot of code sharing between the AtomPub and the Web Services binding. (I couldn't find a Web Services client in Chemistry. It would be great if you could contribute one. Here we are with a working code base that we cannot give up and that we will maintain in the future for obvious reasons. Our idea was to make it Open Source and let others benefit from our work. Apache seemed to be the right place - at least three days ago. OK, I'm new to this Apache thing, but I don't believe this is the Apache Way. See: http://theapacheway.com/ or http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009 S. -- 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Well, here is a citation from http://www.apache.org/foundation/how-it-works.html (section "The Foundation Incubator"): "It must be noted that the incubator (just like the board) does not perform filtering on the basis of technical issues. This is because the foundation respects and suggests variety of technical approaches. It doesn't fear innovation or even internal confrontation between projects which overlap in functionality." Florian -Original Message- From: Stefane Fermigier [mailto:s...@nuxeo.com] Sent: Friday, December 11, 2009 7:46 PM To: chemistry-...@incubator.apache.org Cc: Incubator-General Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS) On Dec 11, 2009, at 7:10 PM, Florian Müller wrote: > > Chemistry uses Abdera to communicate with the server while OpenCMIS > is based on JAX-B and some CMIS specific XML coding. I've been personally asking myself recently wether it would be feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO it's something that should be discussed together and not a division line for us. > There is a lot of code sharing between the AtomPub and the Web > Services binding. (I couldn't find a Web Services client in Chemistry. It would be great if you could contribute one. > Here we are with a working code base that we cannot give up and that > we will maintain in the future for obvious reasons. Our idea was to > make it Open Source and let others benefit from our work. Apache > seemed to be the right place - at least three days ago. OK, I'm new to this Apache thing, but I don't believe this is the Apache Way. See: http://theapacheway.com/ or http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009 S. -- 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Hi,
On Fri, Dec 11, 2009 at 7:10 PM, Florian Müller wrote:
> But you are actually comparing two different levels of APIs. The
> opencmis-provider-api handles simple immutable data objects while
> chemistry-api follows an object-oriented approach. As far as I know
> Chemistry has nothing comparable to the opencmis-provider-api.
I wouldn't say so. For example, here's how you get selected properties
of an object in a given repository (assuming I've understood the APIs
correctly):
OpenCMIS:
CmisProvider provider = ...;
ObjectService service = provider.getObjectService();
PropertiesData data = service.getProperties(
"repositoryId", "objectId", "filter", ...);
Map> properties = data.getProperties();
Chemistry:
RepositoryService service = ...;
SPI spi = service.getRepository("repositoryId").getSPI();
ObjectEntry entry = spi.getProperties(
spi.newObjectId("objectId"), new Inclusion("filter", ...));
Map properties = entry.getValues();
I'd don't think the APIs are too different. At least they certainly
are comparable.
Would it at least make sense for the projects to share a common
org.apache.cmis package with with things like constants defined in the
CMIS standard and other basic concepts that everyone can agree with?
> We derived our design from a lot of prototypes and applications that we
> have built over the past 20 months. Some code fragments and concepts
> are actually pretty old now. We had a lot of it in one shape or another when
> Chemistry started. That's why Chemistry was never an option for us.
> The code bases of Chemistry and OpenCMIS have been developed at the
> same time taking different routes. Chemistry did that in the public, most
> of OpenCMIS was created behind closed doors.
This paragraph should definitely go into the OpenCMIS proposal. It
gives a much clearer rationale for the separate project than the API
and scope differences mentioned in the original proposal.
I definitely understand the value of the existing code base. It's a
bit unfortunate that we now have two codebases for pretty much the
same thing, but I guess we just have to live with that for now. In
fact some healthy competition may even be good for both projects. In
the interest of avoiding further fragmentation I'd like for us to find
ways for the two projects to coexists and cooperate. To do that, I'd
be happy to help mentor OpenCMIS either as a part of Chemistry or as a
separate podling.
BR,
Jukka Zitting
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Florian Müller wrote: Well, here is a citation from http://www.apache.org/foundation/how-it-works.html (section "The Foundation Incubator"): "It must be noted that the incubator (just like the board) does not perform filtering on the basis of technical issues. This is because the foundation respects and suggests variety of technical approaches. It doesn't fear innovation or even internal confrontation between projects which overlap in functionality." right and as long as OpenCMIS fulfills the requirements of the incubator I don't see any reason why there shouldn't be two projects of the same topic. I also do not see any reason why OpenCMIS should be a sub-project of Chemistry. Give it a chance of its own within the current rules of the incubator and it will either work or not. If it works, then graduate, if not, then remove it. Or am I missing something which violates any current rule of the incubator? Cheers Michael Florian -Original Message- From: Stefane Fermigier [mailto:s...@nuxeo.com] Sent: Friday, December 11, 2009 7:46 PM To: chemistry-...@incubator.apache.org Cc: Incubator-General Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS) On Dec 11, 2009, at 7:10 PM, Florian Müller wrote: Chemistry uses Abdera to communicate with the server while OpenCMIS is based on JAX-B and some CMIS specific XML coding. I've been personally asking myself recently wether it would be feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO it's something that should be discussed together and not a division line for us. There is a lot of code sharing between the AtomPub and the Web Services binding. (I couldn't find a Web Services client in Chemistry. It would be great if you could contribute one. Here we are with a working code base that we cannot give up and that we will maintain in the future for obvious reasons. Our idea was to make it Open Source and let others benefit from our work. Apache seemed to be the right place - at least three days ago. OK, I'm new to this Apache thing, but I don't believe this is the Apache Way. See: http://theapacheway.com/ or http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009 S. -- 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
OK, I personally believe this is in contradiction with the first commandment of the Apache Way: "*Community over Code* is a frequent saying that exemplifies ASF projects. Community uses Openness and Merit, expressed through Collaborative and Consensus driven work, to build lasting projects that use a Pragmatic License. While a diverse community is a requirement for every ASF project, we also expect people to contribute as Individuals, and wear appropriate Hats." -> Let our Apache Foundation overlords decide. I still think that at least there should be common code (ex: constants, as suggested by Jukka) and I hope that this will the case, in any case. S. On Dec 11, 2009, at 11:18 PM, Michael Wechner wrote: Florian Müller wrote: Well, here is a citation from http://www.apache.org/foundation/how-it-works.html (section "The Foundation Incubator"): "It must be noted that the incubator (just like the board) does not perform filtering on the basis of technical issues. This is because the foundation respects and suggests variety of technical approaches. It doesn't fear innovation or even internal confrontation between projects which overlap in functionality." right and as long as OpenCMIS fulfills the requirements of the incubator I don't see any reason why there shouldn't be two projects of the same topic. I also do not see any reason why OpenCMIS should be a sub-project of Chemistry. Give it a chance of its own within the current rules of the incubator and it will either work or not. If it works, then graduate, if not, then remove it. Or am I missing something which violates any current rule of the incubator? Cheers Michael Florian -Original Message- From: Stefane Fermigier [mailto:s...@nuxeo.com] Sent: Friday, December 11, 2009 7:46 PM To: chemistry-...@incubator.apache.org Cc: Incubator-General Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS) On Dec 11, 2009, at 7:10 PM, Florian Müller wrote: Chemistry uses Abdera to communicate with the server while OpenCMIS is based on JAX-B and some CMIS specific XML coding. I've been personally asking myself recently wether it would be feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO it's something that should be discussed together and not a division line for us. There is a lot of code sharing between the AtomPub and the Web Services binding. (I couldn't find a Web Services client in Chemistry. It would be great if you could contribute one. Here we are with a working code base that we cannot give up and that we will maintain in the future for obvious reasons. Our idea was to make it Open Source and let others benefit from our work. Apache seemed to be the right place - at least three days ago. OK, I'm new to this Apache thing, but I don't believe this is the Apache Way. See: http://theapacheway.com/ or http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009 S. -- 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Sat, Dec 12, 2009 at 10:27 AM, Stefane Fermigier wrote: > OK, I personally believe this is in contradiction with the first commandment > of the Apache Way: > > "*Community over Code* is a frequent saying that exemplifies ASF projects. > Community uses Openness and Merit, expressed through Collaborative and > Consensus driven work, to build lasting projects that use a Pragmatic > License. While a diverse community is a requirement for every ASF project, > we also expect people to contribute as Individuals, and wear appropriate > Hats." > > -> Let our Apache Foundation overlords decide... Too bad...there are no overlords here ;-) Some of us are speaking as members of the Incubator PMC, having seen a few podlings succeed or fail, and trying to ensure success of at least one (or maybe two if that's needed) CMIS podlings. But in the end it's a decision of the whole Incubator PMC, which I imagine is heavily influenced by having a champion and a few mentors take care of the podling. In my case, the lukewarm welcome to OpenCMIS is mostly due to the fact that nothing was discussed with Chemistry before making the proposal. To me that feels like doing things behind the Chemistry team's back, which I don't like. Hopefully that's being sorted out with the current discussions. > ...I still think that at least there should be common code (ex: constants, as > suggested by Jukka) and I hope that this will the case, in any case Sure - that's also possible by sharing code, for example by giving write access to both Chemistry and OpemCMIS committers to some part of each other's code repository. I'd much prefer having a single project, as I said before, but two projects that collaborate on common parts (like a test suite I imagine) can work as well. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Stefane Fermigier schrieb: OK, I personally believe this is in contradiction with the first commandment of the Apache Way: "*Community over Code* is a frequent saying that exemplifies ASF projects. Community uses Openness and Merit, expressed through Collaborative and Consensus driven work, to build lasting projects that use a Pragmatic License. While a diverse community is a requirement for every ASF project, we also expect people to contribute as Individuals, and wear appropriate Hats." I cannot see any contradiction. Can you explain where exactly you see the contradiction? -> Let our Apache Foundation overlords decide. who are you refering to? I still think that at least there should be common code (ex: constants, as suggested by Jukka) and I hope that this will the case, in any case. Maybe you want to go one step towards OpenCMIS and make a concrete suggestion what you think could be shared and I am quite certain the OpenCMIS guys will also make a step towards Chemistry as well and I am confident collaboration will happen, but yes somebody has to make a first step and maybe it is even an advantage to take this first step ;-) Cheers Michael S. On Dec 11, 2009, at 11:18 PM, Michael Wechner wrote: Florian Müller wrote: Well, here is a citation from http://www.apache.org/foundation/how-it-works.html (section "The Foundation Incubator"): "It must be noted that the incubator (just like the board) does not perform filtering on the basis of technical issues. This is because the foundation respects and suggests variety of technical approaches. It doesn't fear innovation or even internal confrontation between projects which overlap in functionality." right and as long as OpenCMIS fulfills the requirements of the incubator I don't see any reason why there shouldn't be two projects of the same topic. I also do not see any reason why OpenCMIS should be a sub-project of Chemistry. Give it a chance of its own within the current rules of the incubator and it will either work or not. If it works, then graduate, if not, then remove it. Or am I missing something which violates any current rule of the incubator? Cheers Michael Florian -Original Message- From: Stefane Fermigier [mailto:s...@nuxeo.com] Sent: Friday, December 11, 2009 7:46 PM To: chemistry-...@incubator.apache.org Cc: Incubator-General Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS) On Dec 11, 2009, at 7:10 PM, Florian Müller wrote: Chemistry uses Abdera to communicate with the server while OpenCMIS is based on JAX-B and some CMIS specific XML coding. I've been personally asking myself recently wether it would be feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO it's something that should be discussed together and not a division line for us. There is a lot of code sharing between the AtomPub and the Web Services binding. (I couldn't find a Web Services client in Chemistry. It would be great if you could contribute one. Here we are with a working code base that we cannot give up and that we will maintain in the future for obvious reasons. Our idea was to make it Open Source and let others benefit from our work. Apache seemed to be the right place - at least three days ago. OK, I'm new to this Apache thing, but I don't believe this is the Apache Way. See: http://theapacheway.com/ or http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009 S. -- 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Michael Wechner a écrit : Stefane Fermigier schrieb: OK, I personally believe this is in contradiction with the first commandment of the Apache Way: "*Community over Code* is a frequent saying that exemplifies ASF projects. Community uses Openness and Merit, expressed through Collaborative and Consensus driven work, to build lasting projects that use a Pragmatic License. While a diverse community is a requirement for every ASF project, we also expect people to contribute as Individuals, and wear appropriate Hats." I cannot see any contradiction. Can you explain where exactly you see the contradiction? Hi, I just grab the description of both projects : "OpenCMIS will deliver a Java implementation of the OASIS CMIS specification." "Apache Chemistry is a generic Java language implementation of the upcoming OASIS CMIS specification. " I barely see how two communities working on two projects with the very same target can't collaborate and form the best possible community to fulfill this target, leveraging the great people from both of the current project... This is where I see a contradiction : it seems like there is some divergence on the technical side, which is not really the Incubator concern. What is important to us is that a community is built, because it's the guarantee for a long term existence for the project. We don't have the resources and time to setup a darwinian process here :) my 2 cts ... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Fri, Dec 11, 2009 at 11:18 PM, Michael Wechner wrote: > Right and as long as OpenCMIS fulfills the requirements of the incubator I > don't see any reason why there shouldn't be two projects of the same topic. > > I also do not see any reason why OpenCMIS should be a sub-project of > Chemistry. > Give it a chance of its own within the current rules of the incubator and it > will either work or not. > If it works, then graduate, if not, then remove it. My concern is that if there are two separate svn trees then factoring things between the two projects will be much harder. Let's not kid ourselves, having two different maven release cycles, and having dependencies to foreign SNAPSHOT projects, will not help. To me it's a waste of time and effort. Let me ask the question differently: what's lost by having the code in the Chemistry svn tree? 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
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
- Original Message > From: Florent Guillaume > To: general@incubator.apache.org > Cc: chemistry-...@incubator.apache.org > Sent: Sat, December 12, 2009 10:35:18 AM > Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement > Interoperability Services (CMIS) > > On Fri, Dec 11, 2009 at 11:18 PM, Michael Wechner > wrote: > > Right and as long as OpenCMIS fulfills the requirements of the incubator I > > don't see any reason why there shouldn't be two projects of the same topic. > > > > I also do not see any reason why OpenCMIS should be a sub-project of > > Chemistry. > > Give it a chance of its own within the current rules of the incubator and it > > will either work or not. > > If it works, then graduate, if not, then remove it. > > My concern is that if there are two separate svn trees then factoring > things between the two projects will be much harder. Let's not kid > ourselves, having two different maven release cycles, and having > dependencies to foreign SNAPSHOT projects, will not help. To me it's a > waste of time and effort. > > Let me ask the question differently: what's lost by having the code in > the Chemistry svn tree? Sovereignty over the codebase for one. At this point I don't see why people are so concerned with the (lack of) alignment with Chemistry. If the people who wish to work on this proposal prefer to go it alone for the time being, so be it. If a community doesn't emerge out of one project or the other, it's an easier decision to make at that time then it is to predict in advance right now. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Emmanuel Lcharny wrote: Michael Wechner a écrit : Stefane Fermigier schrieb: OK, I personally believe this is in contradiction with the first commandment of the Apache Way: "*Community over Code* is a frequent saying that exemplifies ASF projects. Community uses Openness and Merit, expressed through Collaborative and Consensus driven work, to build lasting projects that use a Pragmatic License. While a diverse community is a requirement for every ASF project, we also expect people to contribute as Individuals, and wear appropriate Hats." I cannot see any contradiction. Can you explain where exactly you see the contradiction? Hi, I just grab the description of both projects : "OpenCMIS will deliver a Java implementation of the OASIS CMIS specification." "Apache Chemistry is a generic Java language implementation of the upcoming OASIS CMIS specification. " I barely see how two communities working on two projects with the very same target can't collaborate and form the best possible community to fulfill this target, leveraging the great people from both of the current project... This is where I see a contradiction : it seems like there is some divergence on the technical side, which is not really the Incubator concern. What is important to us is that a community is built, because it's the guarantee for a long term existence for the project. We don't have the resources and time to setup a darwinian process here :) I am not sure what exactly you mean with "we", but I would argue that the CMS community out there is rather large and has enough potential to provide contributors for both projects. It's up to each incubator project itself to build a healthy community and AFAIK these rules are clear and in particular what it takes to leave the incubator. So either a project will make it or not. I am assuming this is what the incubator is good for, right? Cheers Michael my 2 cts ... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Florent Guillaume wrote: On Fri, Dec 11, 2009 at 11:18 PM, Michael Wechner wrote: Right and as long as OpenCMIS fulfills the requirements of the incubator I don't see any reason why there shouldn't be two projects of the same topic. I also do not see any reason why OpenCMIS should be a sub-project of Chemistry. Give it a chance of its own within the current rules of the incubator and it will either work or not. If it works, then graduate, if not, then remove it. My concern is that if there are two separate svn trees then factoring things between the two projects will be much harder. Let's not kid ourselves, having two different maven release cycles, and having dependencies to foreign SNAPSHOT projects, will not help. To me it's a waste of time and effort. Let me ask the question differently: what's lost by having the code in the Chemistry svn tree? Beside that I agree with Joe's email I would additionally argue that you can easily share code without being within the same project and having it separate from each other it forces you to make the architecture/code even better, which I think has (nearly) only advantages. Cheers Michael Florent - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Michael Wechner a écrit : Emmanuel Lcharny wrote: Michael Wechner a écrit : Stefane Fermigier schrieb: OK, I personally believe this is in contradiction with the first commandment of the Apache Way: "*Community over Code* is a frequent saying that exemplifies ASF projects. Community uses Openness and Merit, expressed through Collaborative and Consensus driven work, to build lasting projects that use a Pragmatic License. While a diverse community is a requirement for every ASF project, we also expect people to contribute as Individuals, and wear appropriate Hats." I cannot see any contradiction. Can you explain where exactly you see the contradiction? Hi, I just grab the description of both projects : "OpenCMIS will deliver a Java implementation of the OASIS CMIS specification." "Apache Chemistry is a generic Java language implementation of the upcoming OASIS CMIS specification. " I barely see how two communities working on two projects with the very same target can't collaborate and form the best possible community to fulfill this target, leveraging the great people from both of the current project... This is where I see a contradiction : it seems like there is some divergence on the technical side, which is not really the Incubator concern. What is important to us is that a community is built, because it's the guarantee for a long term existence for the project. We don't have the resources and time to setup a darwinian process here :) I am not sure what exactly you mean with "we", but I would argue that the CMS community out there is rather large and has enough potential to provide contributors for both projects. It's up to each incubator project itself to build a healthy community and AFAIK these rules are clear and in particular what it takes to leave the incubator. So either a project will make it or not. I am assuming this is what the incubator is good for, right? Would the Incubator be a place where projects enter and try to develop and succeed per their technical merit only, I would agree. But it involves people with a limited timeframe (mentors, champion, PMC members), and I feel that it's a bit a waste to see two projects trying to implement the exact same spec unable to collaborate. I mean, both teams most certainly have their own merit, I won't argue this point, but at some point a bit less ego and a bit more collaboration will generate a better result. I see where Joe is going to with his "let both project get in and let's see which one will survive", I can't help but thinking that beside the rules, there is a spirit which is way more important. At least, let's try... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
- Original Message > From: Emmanuel Lcharny > To: general@incubator.apache.org > Sent: Sat, December 12, 2009 7:32:53 PM > Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement > Interoperability Services (CMIS) > > Michael Wechner a écrit : > > Emmanuel Lcharny wrote: > >> Michael Wechner a écrit : > >>> Stefane Fermigier schrieb: > >>>> OK, I personally believe this is in contradiction with the first > commandment of the Apache Way: > >>>> > >>>> "*Community over Code* is a frequent saying that exemplifies ASF > >>>> projects. > Community uses Openness and Merit, expressed through Collaborative and > Consensus > driven work, to build lasting projects that use a Pragmatic License. While a > diverse community is a requirement for every ASF project, we also expect > people > to contribute as Individuals, and wear appropriate Hats." > >>> > >>> I cannot see any contradiction. Can you explain where exactly you see the > contradiction? > >> Hi, > >> > >> I just grab the description of both projects : > >> > >> "OpenCMIS will deliver a Java implementation of the OASIS CMIS > specification." > >> > >> "Apache Chemistry is a generic Java language implementation of the > >> upcoming > OASIS CMIS specification. " > >> > >> I barely see how two communities working on two projects with the very > >> same > target can't collaborate and form the best possible community to fulfill this > target, leveraging the great people from both of the current project... > >> > >> This is where I see a contradiction : it seems like there is some > >> divergence > on the technical side, which is not really the Incubator concern. What is > important to us is that a community is built, because it's the guarantee for > a > long term existence for the project. We don't have the resources and time to > setup a darwinian process here :) > > > > I am not sure what exactly you mean with "we", but I would argue that the > > CMS > community out there is rather large and has enough > > potential to provide contributors for both projects. > > > > It's up to each incubator project itself to build a healthy community and > AFAIK these rules are clear and in particular what it takes to leave the > incubator. > > So either a project will make it or not. I am assuming this is what the > incubator is good for, right? > > Would the Incubator be a place where projects enter and try to develop and > succeed per their technical merit only, I would agree. But it involves people > with a limited timeframe (mentors, champion, PMC members), and I feel that > it's > a bit a waste to see two projects trying to implement the exact same spec > unable > to collaborate. I mean, both teams most certainly have their own merit, I > won't > argue this point, but at some point a bit less ego and a bit more > collaboration > will generate a better result. > > I see where Joe is going to with his "let both project get in and let's see > which one will survive", I can't help but thinking that beside the rules, > there > is a spirit which is way more important. > > At least, let's try... The way I see it the purpose of a proposal is to attract mentors to the proposal. Given that Chemistry is already here, and contains lots of people who know how to build communities around the code, I can understand the reluctance to support a competing effort by some people. But Apache is a big organization, certainly big enough for two entries into the CMIS market if things work out that way. But I am always skeptical about a project with closed-source origins without a decent contingent of Apache people already involved. Let me also make it clear that I have no interest in either project, so my remarks are meant to be taken as coming from a distance. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Joe Schaefer a écrit : I see where Joe is going to with his "let both project get in and let's see which one will survive", I can't help but thinking that beside the rules, there is a spirit which is way more important. At least, let's try... The way I see it the purpose of a proposal is to attract mentors to the proposal. Given that Chemistry is already here, and contains lots of people who know how to build communities around the code, I can understand the reluctance to support a competing effort by some people. I must admit that it's human nature, but I think - but I'm probably optimistic - that people working on an apache project should overcome this reluctance. In this very case, as Chemistry has entered the incubator more than 6 months ago, I can understand that 'merging' with OpenCMIS would slow down the process, and OTOH, OpenCMIS may not like the idea to be seen as a sub-project... But this is the Incubator, the perfect place yo work out such problems. My fear is that by accepting two separate projects, one may die (or even both), because of the lack of community... It seems less likely if both project work out a common solution, IMHO. Collaboration does not kill good ideas... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
The Board has in the past condemned "balkanization" of community, and my take on this situation is exactly that. This is not "yet another web framework", which often brought forward as examples that the ASF encourages competition within. Those typically have a different "angle", "approach" or "metaphor", something making each very different beasts. But in this case we are talking about "the same spec". There is no real distinguishing features and huge overlap of commonality. I think this is a NIH-syndrome in play, in the best case "oh we have the code working already" and the worst case "we don't like to collaborate with them", and there is reason to think that that goes for both sides of the fence. I want to see Chemistry capable to absorb such contribution and collaborate heavily to bring such codebase in. And I want to see the people of the OpenCMIS proposal to show that they indeed can work with others. Exactly how the merged community goes about with the technical integration is its own business, but I am worried that the new codebase will not receive the welcome I hope, the Chemistry base will dominate, and the OpenCMIS proposer get fed up and leaves. Important Mentors understand the risks here, and keep eyes extra open for attrition, domination and forceful consensus-seeking. I think discussion should continue on Chemistry dev@ list. If agreement can't be reached there, then I am NOT in favor of incubating OpenCMIS separately and will vote -1 to such proposal. I will also form myself an opinion of how well Chemistry is trying to collaborate, and it may improve or deteriorate its status with me. This can become an excellent opportunity for all involved to show off their ApacheWay skills -- Niclas On 13 Dec 2009 09:47, "Emmanuel LŽcharny" wrote: Joe Schaefer a écrit : > > > >> >> I see where Joe is going to with his "let both project get in and > let's see which one will su... > I must admit that it's human nature, but I think - but I'm probably optimistic - that people working on an apache project should overcome this reluctance. In this very case, as Chemistry has entered the incubator more than 6 months ago, I can understand that 'merging' with OpenCMIS would slow down the process, and OTOH, OpenCMIS may not like the idea to be seen as a sub-project... But this is the Incubator, the perfect place yo work out such problems. My fear is that by accepting two separate projects, one may die (or even both), because of the lack of community... It seems less likely if both project work out a common solution, IMHO. Collaboration does not kill good ideas... - To unsubscribe, e-mail: g...
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Sun, Dec 13, 2009 at 2:42 AM, Niclas Hedhman wrote: > The Board has in the past condemned "balkanization" of community, and my > take on this situation is exactly that. > > This is not "yet another web framework", which often brought forward as > examples that the ASF encourages competition within. Those typically have a > different "angle", "approach" or "metaphor", something making each very > different beasts. But in this case we are talking about "the same spec". > There is no real distinguishing features and huge overlap of commonality. > > I think this is a NIH-syndrome in play, in the best case "oh we have the > code working already" and the worst case "we don't like to collaborate with > them", and there is reason to think that that goes for both sides of the > fence. > > I want to see Chemistry capable to absorb such contribution and collaborate > heavily to bring such codebase in. > And I want to see the people of the OpenCMIS proposal to show that they > indeed can work with others. > > Exactly how the merged community goes about with the technical integration > is its own business, but I am worried that the new codebase will not receive > the welcome I hope, the Chemistry base will dominate, and the OpenCMIS > proposer get fed up and leaves. Important Mentors understand the risks here, > and keep eyes extra open for attrition, domination and forceful > consensus-seeking. > I agree with those sentiments. > I think discussion should continue on Chemistry dev@ list. If agreement > can't be reached there, then I am NOT in favor of incubating OpenCMIS > separately and will vote -1 to such proposal. I will also form myself an > opinion of how well Chemistry is trying to collaborate, and it may improve > or deteriorate its status with me. > I don't think it would be helpful for either OpenCMIS or Chemistry for the IPMC to just unilaterally dictate that "it must be done in Chemistry". IMHO that would make for too unlevel a playing field which could adversely impact any attempts to collaborate (or even just get stuff done). That works both ways - it would be hard for OpenCMIS being forced to be part of Chemistry, but also potentially hard for Chemistry to all of a sudden have a significant number of new committers forced upon them and upsetting the status quo. The Incubator has always been very clear about having a very low bar of entry to incubation so IMHO it shouldn't matter that the incoming podling is doing the same spec as another poddling, thats something that could be worked out during incubation. So I'd +1 accepting this new OpenCMIS proposal (if they can find champion and mentors). If we're really concerned about having multiple spec impls then we can make this a graduation requirement - neither Chemistry or OpenCMIS graduate until they've both worked out how to exist together. > This can become an excellent opportunity for all involved to show off their > ApacheWay skills > +1! > -- Niclas > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Dec 12, 2009, at 1:36 PM, Michael Wechner wrote: Stefane Fermigier schrieb: OK, I personally believe this is in contradiction with the first commandment of the Apache Way: "*Community over Code* is a frequent saying that exemplifies ASF projects. Community uses Openness and Merit, expressed through Collaborative and Consensus driven work, to build lasting projects that use a Pragmatic License. While a diverse community is a requirement for every ASF project, we also expect people to contribute as Individuals, and wear appropriate Hats." I cannot see any contradiction. Can you explain where exactly you see the contradiction? As I understand it, the Apache Way means that building consensus has more value than a code base that can be donated but can't be modified because, well, there are good reasons not to do it. -> Let our Apache Foundation overlords decide. who are you refering to? I'm not familiar with the process, but I understand that some people are going to be responsible for deciding who will graduate and who won't. I still think that at least there should be common code (ex: constants, as suggested by Jukka) and I hope that this will the case, in any case. Maybe you want to go one step towards OpenCMIS and make a concrete suggestion what you think could be shared and I am quite certain the OpenCMIS guys will also make a step towards Chemistry as well and I am confident collaboration will happen, but yes somebody has to make a first step and maybe it is even an advantage to take this first step ;-) I think suggestions have already been made. S. -- 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
So basically what you mean is: "competition, over collaboration" ? S. On Dec 12, 2009, at 6:55 PM, Joe Schaefer wrote: - Original Message From: Florent Guillaume To: general@incubator.apache.org Cc: chemistry-...@incubator.apache.org Sent: Sat, December 12, 2009 10:35:18 AM Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS) On Fri, Dec 11, 2009 at 11:18 PM, Michael Wechner wrote: Right and as long as OpenCMIS fulfills the requirements of the incubator I don't see any reason why there shouldn't be two projects of the same topic. I also do not see any reason why OpenCMIS should be a sub-project of Chemistry. Give it a chance of its own within the current rules of the incubator and it will either work or not. If it works, then graduate, if not, then remove it. My concern is that if there are two separate svn trees then factoring things between the two projects will be much harder. Let's not kid ourselves, having two different maven release cycles, and having dependencies to foreign SNAPSHOT projects, will not help. To me it's a waste of time and effort. Let me ask the question differently: what's lost by having the code in the Chemistry svn tree? Sovereignty over the codebase for one. At this point I don't see why people are so concerned with the (lack of) alignment with Chemistry. If the people who wish to work on this proposal prefer to go it alone for the time being, so be it. If a community doesn't emerge out of one project or the other, it's an easier decision to make at that time then it is to predict in advance right now. -- 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Stefane Fermigier wrote: On Dec 12, 2009, at 1:36 PM, Michael Wechner wrote: Stefane Fermigier schrieb: OK, I personally believe this is in contradiction with the first commandment of the Apache Way: "*Community over Code* is a frequent saying that exemplifies ASF projects. Community uses Openness and Merit, expressed through Collaborative and Consensus driven work, to build lasting projects that use a Pragmatic License. While a diverse community is a requirement for every ASF project, we also expect people to contribute as Individuals, and wear appropriate Hats." I cannot see any contradiction. Can you explain where exactly you see the contradiction? As I understand it, the Apache Way means that building consensus has more value than a code base that can be donated but can't be modified because, well, there are good reasons not to do it. are you refering to the OpenCMIS code? If so, then please say so and give the OpenCMIS folks a change to prove different. -> Let our Apache Foundation overlords decide. who are you refering to? I'm not familiar with the process, but I understand that some people are going to be responsible for deciding who will graduate and who won't. maybe you want to take a look at http://incubator.apache.org/guides/graduation.html since I guess this also matters to Chemistry ;-) I still think that at least there should be common code (ex: constants, as suggested by Jukka) and I hope that this will the case, in any case. Maybe you want to go one step towards OpenCMIS and make a concrete suggestion what you think could be shared and I am quite certain the OpenCMIS guys will also make a step towards Chemistry as well and I am confident collaboration will happen, but yes somebody has to make a first step and maybe it is even an advantage to take this first step ;-) I think suggestions have already been made. are you refering to Jukka's suggestions? Of which suggestions exactly? @OpenCMIS folks: What is your point of view re Jukka's suggestions? Cheers Michael S. -- 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Niclas Hedhman wrote: The Board has in the past condemned "balkanization" of community, and my take on this situation is exactly that. This is not "yet another web framework", which often brought forward as examples that the ASF encourages competition within. Those typically have a different "angle", "approach" or "metaphor", something making each very different beasts. But in this case we are talking about "the same spec". There is no real distinguishing features and huge overlap of commonality. there isn't just one JCR implementation and I am glad there is a choice and some healthy competition. Yes, the ASF only hosts one JCR implementation, but would it matter if another would be part of the ASF? I don't think it would matter, but it would rather show that the ASF is really open-minded about different approaches. I think this is a NIH-syndrome in play, in the best case "oh we have the code working already" and the worst case "we don't like to collaborate with them", and there is reason to think that that goes for both sides of the fence. if so, then let's be specific on this and parties should explain themselves re this particular "allegation" I want to see Chemistry capable to absorb such contribution and collaborate heavily to bring such codebase in. And I want to see the people of the OpenCMIS proposal to show that they indeed can work with others. Exactly how the merged community goes about with the technical integration is its own business, but I am worried that the new codebase will not receive the welcome I hope, the Chemistry base will dominate, and the OpenCMIS proposer get fed up and leaves. Important Mentors understand the risks here, and keep eyes extra open for attrition, domination and forceful consensus-seeking. I think discussion should continue on Chemistry dev@ list. If agreement can't be reached there, then I am NOT in favor of incubating OpenCMIS separately and will vote -1 to such proposal. that seems to me very wrong. If you have two folks speaking to each other and in the end they find out that they cannot work together for some reason, then we send one of them into the "desert" just because the other one was there first (especially if you have enough space actually). Let's first see how the discussion goes and then decide how to continue. I will also form myself an opinion of how well Chemistry is trying to collaborate, and it may improve or deteriorate its status with me. This can become an excellent opportunity for all involved to show off their ApacheWay skills I would be glad if we could stop refering to the ApacheWay, because AFAIK there is no strict definition of the ApacheWay. I would rather prefer if we could be specific, for example that both parties make a concrete list, where they are different code-wise and why they think it is not possible to merge the code initially and also make a plan what the common "interfaces" could be initially and in the future. Thanks Michael -- Niclas On 13 Dec 2009 09:47, "Emmanuel LŽcharny" wrote: Joe Schaefer a écrit : I see where Joe is going to with his "let both project get in and let's see which one will su... I must admit that it's human nature, but I think - but I'm probably optimistic - that people working on an apache project should overcome this reluctance. In this very case, as Chemistry has entered the incubator more than 6 months ago, I can understand that 'merging' with OpenCMIS would slow down the process, and OTOH, OpenCMIS may not like the idea to be seen as a sub-project... But this is the Incubator, the perfect place yo work out such problems. My fear is that by accepting two separate projects, one may die (or even both), because of the lack of community... It seems less likely if both project work out a common solution, IMHO. Collaboration does not kill good ideas... - To unsubscribe, e-mail: g... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
- Original Message > From: Niclas Hedhman > To: general@incubator.apache.org > Sent: Sat, December 12, 2009 9:42:21 PM > Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement > Interoperability Services (CMIS) > > The Board has in the past condemned "balkanization" of community, and my > take on this situation is exactly that. > > This is not "yet another web framework", which often brought forward as > examples that the ASF encourages competition within. Those typically have a > different "angle", "approach" or "metaphor", something making each very > different beasts. But in this case we are talking about "the same spec". > There is no real distinguishing features and huge overlap of commonality. > > I think this is a NIH-syndrome in play, in the best case "oh we have the > code working already" and the worst case "we don't like to collaborate with > them", and there is reason to think that that goes for both sides of the > fence. > > I want to see Chemistry capable to absorb such contribution and collaborate > heavily to bring such codebase in. > And I want to see the people of the OpenCMIS proposal to show that they > indeed can work with others. > > Exactly how the merged community goes about with the technical integration > is its own business, but I am worried that the new codebase will not receive > the welcome I hope, the Chemistry base will dominate, and the OpenCMIS > proposer get fed up and leaves. Important Mentors understand the risks here, > and keep eyes extra open for attrition, domination and forceful > consensus-seeking. > > I think discussion should continue on Chemistry dev@ list. If agreement > can't be reached there, then I am NOT in favor of incubating OpenCMIS > separately and will vote -1 to such proposal. I will also form myself an > opinion of how well Chemistry is trying to collaborate, and it may improve > or deteriorate its status with me. > > This can become an excellent opportunity for all involved to show off their > ApacheWay skills I really wish we would confine ourselves to things we understand, and agree with Michael that the injection of platitutes or ultimatums does not help things along. When Etch was proposed they didn't even mention Thrift, even tho they both basically have the same goals. When Doug decided to create Avro instead of participating in Thrift the board didn't wince, not even a little bit. If anything it's time for the people behind the OpenCMIS proposal to do more of the talking, and the people on the IPMC (and in Chemistry IMO) to do less of it. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
hi all, here are my two cents. i believe the cmis community is too small to fork at this point and at least the chemistry part of the community does not want to fork (at least that's my take, as a part of it). so i would personally assume that all chemistry committers would join the opencmis initial committers even before the incubation starts and would actively work in a true commuity effort to consolidate the efforts. the mentors and champions would probably be the same people aswell. so in my mind the bottom-line would be same result as if we had the opencmis people join chemistry, except that we give infra a bit of extra work and create extra effort for the incubator from a reporting perspective... i am sure we can find a good way forward between the two communities. we just need a couple of days to sort things out... keep in mind we all know each other personally ;) regards, david On Sun, Dec 13, 2009 at 10:16 AM, ant elder wrote: > On Sun, Dec 13, 2009 at 2:42 AM, Niclas Hedhman wrote: >> The Board has in the past condemned "balkanization" of community, and my >> take on this situation is exactly that. >> >> This is not "yet another web framework", which often brought forward as >> examples that the ASF encourages competition within. Those typically have a >> different "angle", "approach" or "metaphor", something making each very >> different beasts. But in this case we are talking about "the same spec". >> There is no real distinguishing features and huge overlap of commonality. >> >> I think this is a NIH-syndrome in play, in the best case "oh we have the >> code working already" and the worst case "we don't like to collaborate with >> them", and there is reason to think that that goes for both sides of the >> fence. >> >> I want to see Chemistry capable to absorb such contribution and collaborate >> heavily to bring such codebase in. >> And I want to see the people of the OpenCMIS proposal to show that they >> indeed can work with others. >> >> Exactly how the merged community goes about with the technical integration >> is its own business, but I am worried that the new codebase will not receive >> the welcome I hope, the Chemistry base will dominate, and the OpenCMIS >> proposer get fed up and leaves. Important Mentors understand the risks here, >> and keep eyes extra open for attrition, domination and forceful >> consensus-seeking. >> > > I agree with those sentiments. > >> I think discussion should continue on Chemistry dev@ list. If agreement >> can't be reached there, then I am NOT in favor of incubating OpenCMIS >> separately and will vote -1 to such proposal. I will also form myself an >> opinion of how well Chemistry is trying to collaborate, and it may improve >> or deteriorate its status with me. >> > > I don't think it would be helpful for either OpenCMIS or Chemistry for > the IPMC to just unilaterally dictate that "it must be done in > Chemistry". IMHO that would make for too unlevel a playing field which > could adversely impact any attempts to collaborate (or even just get > stuff done). That works both ways - it would be hard for OpenCMIS > being forced to be part of Chemistry, but also potentially hard for > Chemistry to all of a sudden have a significant number of new > committers forced upon them and upsetting the status quo. > > The Incubator has always been very clear about having a very low bar > of entry to incubation so IMHO it shouldn't matter that the incoming > podling is doing the same spec as another poddling, thats something > that could be worked out during incubation. So I'd +1 accepting this > new OpenCMIS proposal (if they can find champion and mentors). If > we're really concerned about having multiple spec impls then we can > make this a graduation requirement - neither Chemistry or OpenCMIS > graduate until they've both worked out how to exist together. > > >> This can become an excellent opportunity for all involved to show off their >> ApacheWay skills >> > > +1! > >> -- Niclas >> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
> 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Sun, Dec 13, 2009 at 8:41 PM, Joe Schaefer wrote: > When Etch was proposed they didn't even mention Thrift, even tho they both > basically > have the same goals. 1. Etch and Thrift are not involved in specs, and more comparable to "web app framework" domain. 2. Etch is also not in a good state, in reality due to initial diversity problems. And my *claim* is that Avalon was shut down due to exactly this. Two smaller communities wanted to part ways (diff impl of the same "spec"), and Board slapped us so hard on the head it wasn't funny. Am I bitter? No. But I think lack of consistency is not to be taken lightly. For me, the Board's message/actions set a precedent and acting as my guide to what the ASF is about and not. I am surprised Noel has forgotten this episode already ;-) Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Hi, On Wed, Dec 9, 2009 at 6:21 PM, Goetz, Paul 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Sun, Dec 20, 2009 at 2:02 PM, Goetz, Paul 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
