You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Gabriele Columbro <ga...@apache.org> on 2011/02/07 15:07:48 UTC
Product/vendor specific contributions to Chemistry
Hi guys,
this contribution to Alfresco [1] which also comprise a potential
contribution to OpenCMIS is triggering to ask me a more general question on
the list.
What is our (and ASF) position with respect to product specific
contributions? Meaning, do you see any "netiquette" or other issues in
committing this the OpenCMIS codebase?
I think that, especially considering the interop and willingly flexible
nature of the CMIS standard, having product specific extensions might be a
plus for the usability and wider applicability of OpenCMIS.
So I'd be +1 to follow the standard contribution procedure for this (
http://www.apache.org/dev/contributors.html#patches), but WDYT?
Ciao,
Gab
[1] https://issues.alfresco.com/jira/browse/ALF-7088
--
Eng. Gabriele Columbro
Open source and ECM Architect
Alfresco Ltd. - http://www.alfresco.com
-----------------------------------------
-----------------------------------------
"Keyboard not found.
Press F1 to continue"
-----------------------------------------
Re: Product/vendor specific contributions to Chemistry
Posted by Florian Müller <fl...@alfresco.com>.
Hi,
I'm indecisive on this one.
On the one hand I think OpenCMIS should be vendor independent. Also, the
OpenCMIS release cycle might not match the vendors release cycle.
On the other hand it would be nice to provide out-of-box connectivity to
as many repositories as possible.
How about keeping the code out of OpenCMIS but providing connection
instructions for different repositories on the Chemistry website?
The instructions could, of course, include links to additional jars that
are required.
I agree with Jens that NTLM is different. It's an independent
authentication protocol - even if it is only used by a few (well, one)
vendor.
If we find more of those, I think they belong into OpenCMIS. Digest
authentication and SSL client certificates come to mind.
- Florian
On 08/02/2011 16:15, Florent Guillaume wrote:
> Hi,
>
> FWIW Nuxeo also has a very similar class for its own kinds of
> tickets-based-on-simple-secrets:
> http://hg.nuxeo.org/addons/nuxeo-chemistry/file/5.4/nuxeo-opencmis-impl/src/main/java/org/nuxeo/ecm/core/opencmis/impl/client/NuxeoPortalSSOAuthenticationProvider.java
>
> There's no vendor-specific dependency in either case, so it's not a
> problem having these classes in Chemistry, although in our case we
> prefer distributing it with the rest of the Nuxeo libraries as the
> semantics of the secret sharing and header use are really part of
> Nuxeo.
>
> Florent
>
>
> On Tue, Feb 8, 2011 at 1:06 PM, Jens Hübel<jh...@opentext.com> wrote:
>> Not sure that I have the full picture yet about the proposed enhancement, but in general I feel it would be better to provide a generic extension point in CMIS with the possibility to drop another Alfresco (or anybody else's) jar on the class path instead of adding dozens of vendor specific extensions to the Chemistry code bases over time.
>>
>> Looking at the motivation mentioned in the issue tracker...
>>
>>> "The default authentication scheme supported by OpenCMIS is HTTP BASIC which is not
>>> suitable for any serious deployment due to the fact that it sends userids and passwords in
>>> the clear at each request
>>
>> ... well if there is anything better that makes sense we should talk about this, but securing a repository is a wider field than just avoiding sending passwords over the wire.
>>
>> The NTLM authentication could be seen as another example of such an integration but for me this is on a different level of "vendor specific".
>>
>> Just my thoughts I am open for discussion...
>>
>> Jens
>>
>>
>> -----Original Message-----
>> From: Nick Burch [mailto:nick.burch@alfresco.com]
>> Sent: Dienstag, 8. Februar 2011 00:21
>> To: chemistry-dev@incubator.apache.org
>> Subject: Re: Product/vendor specific contributions to Chemistry
>>
>> On Mon, 7 Feb 2011, Gabriele Columbro wrote:
>>> this contribution to Alfresco [1] which also comprise a potential
>>> contribution to OpenCMIS is triggering to ask me a more general question
>>> on the list.
>>>
>>> What is our (and ASF) position with respect to product specific
>>> contributions? Meaning, do you see any "netiquette" or other issues in
>>> committing this the OpenCMIS codebase?
>>
>> My gut feeling is that if you can compile the code without needing any
>> Alfresco jars, and if it's a small-ish optional feature, then it probably
>> makes sense to have it in Chemistry so it's easy for people to use. We'd
>> just need to ensure there's always another way to do it though, so people
>> can code generically if they want to.
>>
>> For code that requires Alfresco (or anyone else's) jars to compile
>> against, it'll almost certainly need to be a different module. If that is
>> hosted in Chemistry or outside will depend on both the license, and how
>> close a fit the community feels it is.
>>
>> In this case, I seem to recall there's already an alternate authentication
>> provider for NTLM, so this would seem an OK addition for people who wanted
>> it, which others can ignore if they don't.
>>
>> Nick
>>
>
>
>
Re: Product/vendor specific contributions to Chemistry
Posted by Florent Guillaume <fg...@nuxeo.com>.
Hi,
FWIW Nuxeo also has a very similar class for its own kinds of
tickets-based-on-simple-secrets:
http://hg.nuxeo.org/addons/nuxeo-chemistry/file/5.4/nuxeo-opencmis-impl/src/main/java/org/nuxeo/ecm/core/opencmis/impl/client/NuxeoPortalSSOAuthenticationProvider.java
There's no vendor-specific dependency in either case, so it's not a
problem having these classes in Chemistry, although in our case we
prefer distributing it with the rest of the Nuxeo libraries as the
semantics of the secret sharing and header use are really part of
Nuxeo.
Florent
On Tue, Feb 8, 2011 at 1:06 PM, Jens Hübel <jh...@opentext.com> wrote:
> Not sure that I have the full picture yet about the proposed enhancement, but in general I feel it would be better to provide a generic extension point in CMIS with the possibility to drop another Alfresco (or anybody else's) jar on the class path instead of adding dozens of vendor specific extensions to the Chemistry code bases over time.
>
> Looking at the motivation mentioned in the issue tracker...
>
>> "The default authentication scheme supported by OpenCMIS is HTTP BASIC which is not
>> suitable for any serious deployment due to the fact that it sends userids and passwords in
>> the clear at each request
>
> ... well if there is anything better that makes sense we should talk about this, but securing a repository is a wider field than just avoiding sending passwords over the wire.
>
> The NTLM authentication could be seen as another example of such an integration but for me this is on a different level of "vendor specific".
>
> Just my thoughts I am open for discussion...
>
> Jens
>
>
> -----Original Message-----
> From: Nick Burch [mailto:nick.burch@alfresco.com]
> Sent: Dienstag, 8. Februar 2011 00:21
> To: chemistry-dev@incubator.apache.org
> Subject: Re: Product/vendor specific contributions to Chemistry
>
> On Mon, 7 Feb 2011, Gabriele Columbro wrote:
>> this contribution to Alfresco [1] which also comprise a potential
>> contribution to OpenCMIS is triggering to ask me a more general question
>> on the list.
>>
>> What is our (and ASF) position with respect to product specific
>> contributions? Meaning, do you see any "netiquette" or other issues in
>> committing this the OpenCMIS codebase?
>
> My gut feeling is that if you can compile the code without needing any
> Alfresco jars, and if it's a small-ish optional feature, then it probably
> makes sense to have it in Chemistry so it's easy for people to use. We'd
> just need to ensure there's always another way to do it though, so people
> can code generically if they want to.
>
> For code that requires Alfresco (or anyone else's) jars to compile
> against, it'll almost certainly need to be a different module. If that is
> hosted in Chemistry or outside will depend on both the license, and how
> close a fit the community feels it is.
>
> In this case, I seem to recall there's already an alternate authentication
> provider for NTLM, so this would seem an OK addition for people who wanted
> it, which others can ignore if they don't.
>
> Nick
>
--
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
RE: Product/vendor specific contributions to Chemistry
Posted by Jens Hübel <jh...@opentext.com>.
Not sure that I have the full picture yet about the proposed enhancement, but in general I feel it would be better to provide a generic extension point in CMIS with the possibility to drop another Alfresco (or anybody else's) jar on the class path instead of adding dozens of vendor specific extensions to the Chemistry code bases over time.
Looking at the motivation mentioned in the issue tracker...
> "The default authentication scheme supported by OpenCMIS is HTTP BASIC which is not
> suitable for any serious deployment due to the fact that it sends userids and passwords in
> the clear at each request
... well if there is anything better that makes sense we should talk about this, but securing a repository is a wider field than just avoiding sending passwords over the wire.
The NTLM authentication could be seen as another example of such an integration but for me this is on a different level of "vendor specific".
Just my thoughts I am open for discussion...
Jens
-----Original Message-----
From: Nick Burch [mailto:nick.burch@alfresco.com]
Sent: Dienstag, 8. Februar 2011 00:21
To: chemistry-dev@incubator.apache.org
Subject: Re: Product/vendor specific contributions to Chemistry
On Mon, 7 Feb 2011, Gabriele Columbro wrote:
> this contribution to Alfresco [1] which also comprise a potential
> contribution to OpenCMIS is triggering to ask me a more general question
> on the list.
>
> What is our (and ASF) position with respect to product specific
> contributions? Meaning, do you see any "netiquette" or other issues in
> committing this the OpenCMIS codebase?
My gut feeling is that if you can compile the code without needing any
Alfresco jars, and if it's a small-ish optional feature, then it probably
makes sense to have it in Chemistry so it's easy for people to use. We'd
just need to ensure there's always another way to do it though, so people
can code generically if they want to.
For code that requires Alfresco (or anyone else's) jars to compile
against, it'll almost certainly need to be a different module. If that is
hosted in Chemistry or outside will depend on both the license, and how
close a fit the community feels it is.
In this case, I seem to recall there's already an alternate authentication
provider for NTLM, so this would seem an OK addition for people who wanted
it, which others can ignore if they don't.
Nick
Re: Product/vendor specific contributions to Chemistry
Posted by Nick Burch <ni...@alfresco.com>.
On Mon, 7 Feb 2011, Gabriele Columbro wrote:
> this contribution to Alfresco [1] which also comprise a potential
> contribution to OpenCMIS is triggering to ask me a more general question
> on the list.
>
> What is our (and ASF) position with respect to product specific
> contributions? Meaning, do you see any "netiquette" or other issues in
> committing this the OpenCMIS codebase?
My gut feeling is that if you can compile the code without needing any
Alfresco jars, and if it's a small-ish optional feature, then it probably
makes sense to have it in Chemistry so it's easy for people to use. We'd
just need to ensure there's always another way to do it though, so people
can code generically if they want to.
For code that requires Alfresco (or anyone else's) jars to compile
against, it'll almost certainly need to be a different module. If that is
hosted in Chemistry or outside will depend on both the license, and how
close a fit the community feels it is.
In this case, I seem to recall there's already an alternate authentication
provider for NTLM, so this would seem an OK addition for people who wanted
it, which others can ignore if they don't.
Nick