Mailing-List: contact chemistry-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: chemistry-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of jhuebel@opentext.com designates
 149.235.128.48 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Product/vendor specific contributions to Chemistry
Date: Tue, 8 Feb 2011 13:06:27 +0100
Message-ID: <11E8705F4573E64FB42C724ADC742F6F034E2851@MUCXGC2.opentext.net>
In-Reply-To: <alpine.DEB.1.10.1102072315130.9740@urchin.earth.li>
Thread-Topic: Product/vendor specific contributions to Chemistry
Thread-Index: AcvHHbMGBTowon81TJ6YHEzgzFM/zQAaAxoQ
References: <AANLkTikCPr52PKnZyQook=kGg0Wjz4yeb6o=hFQTUyff@mail.gmail.com>
 <alpine.DEB.1.10.1102072315130.9740@urchin.earth.li>
From: =?iso-8859-1?Q?Jens_H=FCbel?= <jhuebel@opentext.com>
To: <chemistry-dev@incubator.apache.org>

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=20
> suitable for any serious deployment due to the fact that it sends =
userids and passwords in=20
> 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]=20
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=20
> contribution to OpenCMIS is triggering to ask me a more general =
question=20
> 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=20
Alfresco jars, and if it's a small-ish optional feature, then it =
probably=20
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=20
can code generically if they want to.

For code that requires Alfresco (or anyone else's) jars to compile=20
against, it'll almost certainly need to be a different module. If that =
is=20
hosted in Chemistry or outside will depend on both the license, and how=20
close a fit the community feels it is.

In this case, I seem to recall there's already an alternate =
authentication=20
provider for NTLM, so this would seem an OK addition for people who =
wanted=20
it, which others can ignore if they don't.

Nick