chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Hübel <jhue...@opentext.com>
Subject RE: Product/vendor specific contributions to Chemistry
Date Tue, 08 Feb 2011 12:06:27 GMT
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

Mime
View raw message