Mailing-List: contact infrastructure-dev-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: infrastructure-dev@apache.org
Received-SPF: pass (nike.apache.org: domain of elecharny@gmail.com designates
 72.14.220.152 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:organization:user-agent:mime-version
         :to:subject:references:in-reply-to:content-type
         :content-transfer-encoding:sender;
        b=QD79suh9Yp7zeqvZGSbHKBgBvAGG1qBv0NmqDyldo7NG5nBKFNHkRN9QdzNtk7pf9J
         QHkGISRUyWElFRp34B05LHJZf6m62paG2xJ3qhZbCKx224VN7MuSRRYbqyW1s9FoWPLb
         o0pEG58hWZxGHUmp8tBtzZ9DSet0lkPcxLp9I=
Message-ID: <493CDBFC.6090408@apache.org>
Date: Mon, 08 Dec 2008 09:34:04 +0100
From: =?ISO-8859-15?Q?Emmanuel_L=E9charny?= <elecharny@apache.org>
Reply-To: elecharny@apache.org
Organization: The Apache Software Foundation
User-Agent: Thunderbird 2.0.0.18 (X11/20081125)
MIME-Version: 1.0
To: infrastructure-dev@apache.org
Subject: Re: CLAs and LDAP
References: <4939D37A.8010303@apache.org>
  <493A799E.1030703@sharp.fm>	 <1228680161.18635.4.camel@forge.intermeta.com>
  <493C3253.80405@apache.org> <1228703436.18635.32.camel@forge.intermeta.com>
In-Reply-To: <1228703436.18635.32.camel@forge.intermeta.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Sender: Emmanuel Lecharny <elecharny@gmail.com>

Henning Schmiedehausen wrote:
> On Sun, 2008-12-07 at 21:30 +0100, Emmanuel L�charny wrote:
>
> <snip/>
>>> The first one restricts you to having a "CLA attribute". Which means,
>>> when we need a new thing, you need to add another attribute and another
>>> and another. 
>>>   
>>>       
>> Only if we didn't listed the attributes we need before starting to 
>> define the schema. Generally speaking, it might be better to keep the 
>> number of ObjectClass low, because it's a burden from the administration 
>> POV to manage many abstract ObjectClasses (you always have to remember 
>> to add this and that objectClass to get a correct entry).
>>     
>
> Huh? Only if you plan to manage this whole thing by hand. 
Certainly not ! I'm too lazzy ;)
> I use ApacheDS
> Studio all the time and honestly, it is a nice, but very basic schema
> browser, nothing more. If user creation is to be automated, it will have
> to create new user objects anyway, which means that the object class
> assignment has to be correct in there and that is all places that you
> need.
>   
If user creation is to be automated, the best would be to have a 
dedicated UI. Especially if we have to define more than one ObjectClass, 
otherwise, it will be a PITA...

btw, what do you mean by 'user objects' ?
> If you insist on adding users with ldapadd, phpldapadmin or similar
> toys, then yes, you are in a world of pain. But you don't do that in a
> serious context anyway, do you?
>   
cf a previous comment : I'm too lazzy ;)
>
>   
>> Remember that the data structure will change orders of magnitude less 
>> than the data themselves (if we do a correct analysis first, of course ;)
>>     
>
> LOL. The data structure will changes in ways that are unimaginable to
> anyone of us yet all the time. Otherwise we would add them now. So what
> we need to do is to organize the data in a way that it is flexible and
> extensible. That is why I would use multiple object classes and not
> extend existing ones. Along that road lies IME tremendous pain.
>   
Whatever you do, the main issue is _not_ adding some new AttributeType 
to an ObjectClass, but to modify the thousands of entries if you add a 
new mandatory AttributeType. The flexibility is not an issue, the data 
managment is. It's perfectly sane and easy to add a newt AT in a big 
ASFPerson OC, so I don't see any reason not to do so and to define 
dozens of Abstract OC. Not to say that decoupling some part of the 
schema does not make sense, but I want to stress the fact that it's not 
a common practice in LDAP. Just have a look at M$ ObjectClasses :)
>   
>>> What you *want* is a custom object class representing the CLA, e.g.
>>> "CLAPerson". This contains all required attributes (e.g. "CLA on file"
>>> as a boolean and "scannedCLA" as a binary attribute) and if a person is
>>> eligible to a CLA, you just add it to its object classes. Make claOnFile
>>> mandatory and scannedCLA optional and you are good to go.
>>>   
>>>       
>> This is an option. The main issue, IMO, is how to handle CLAs stored in 
>> many files, and CLA type (pdf, tif, ...).
>>     
>
> What is the relevance? Make it a multivalue bianry field and add a mime
> type. 
You can't associate a content and a Mime type in a attribute without 
having to add some structure to your attribute, which will make it 
impossible to manage by a simple ldap browser.  In other words, even if 
you use options, managing both the mime type, the multi-file CLA and the 
content in one single attribute is by no mean simple.

for instance, if you have a PDF CLA in two parts, you may have something 
like :
AsfCLA;pdf;part-1: <blah>
AsfCLA;pdf;part-2: <blah 2>

Now, from the browser perspective, this is quite complicated to manage. 
Assuming that the LDAP server handle options correctly ...

> </snip>


-- 
--
cordialement, regards,
Emmanuel L�charny
www.iktek.com
directory.apache.org