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 Sun, 07 Dec 2008 20:30:11 GMT
Henning Schmiedehausen wrote:
> On Sat, 2008-12-06 at 15:09 +0200, Graham Leggett wrote:
>> Paul Querna wrote:
>>> In the ldap schema, we likely need some way to mark someone as having a 
>>> CLA or not.
>>> We have a couple ASF members, who have never contributed code before, so 
>>> while they would be in the ASF members group, they have not signed a CLA 
>>> -- and therefore should _not_ have access to the public svn code areas.
>>> Maybe having a CLA is just another group?
>> There are two approaches you can take with this.
>> The first is to add an attribute to the person's object, probably with 
>> something sensible in it like the URL of the CLA. The catch is that you 
>> need to add something to the schema for this.
>> The second is to create a group representing people with CLAs on file as 
>> you suggested. This doesn't require any schema change.
> 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).

Remember that the data structure will change orders of magnitude less 
than the data themselves (if we do a correct analysis first, of course ;)
> The second one restricts you on how to organize the tree.
> 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, ...).

About the storage, I think that having a binary multivalued attribute to 
store the CLAs is better than relying on svn. CLAs never change, and 
LDAP can handle those big files.
> And if you look for all the CLA holders, you do a query on
> (&(objectClass=CLAOHolder)(claOnFile=true)
(claOnFile=true) is enough. As this attribute is 'own' by the CLAHolder 
ObjectClass, if the entry does not have this OC, it can't have the 
'claOnFile' attribute, so no need to filter on the objectclass (but you 
will have to index the claOnFile attribute, which is ok)

cordialement, regards,
Emmanuel L├ęcharny

View raw message