www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@apache.org>
Subject Re: CLAs and LDAP
Date Mon, 08 Dec 2008 08:34:04 GMT
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

View raw message