www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henning Schmiedehausen <henn...@schmiedehausen.org>
Subject Re: CLAs and LDAP
Date Mon, 08 Dec 2008 02:30:36 GMT
On Sun, 2008-12-07 at 21:30 +0100, Emmanuel L├ęcharny wrote:

> Henning Schmiedehausen wrote:
> > On Sat, 2008-12-06 at 15:09 +0200, Graham Leggett wrote:
> >   
[...]

> > 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. 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 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?


> 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.

> > 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. The rest is left as an exercise to the reader (Hint: How does a
browser deal with this?).

> 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.

+1

> > 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)

Yes. 

	Ciao
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Java, J2EE, Linux
Mail: henning@schmiedehausen.org    -- Consultant, Architect, Developer
Web:  http://henning.schmiedehausen.org/



Mime
View raw message