Grouper Developers Forum

["Michael R. Gettes" <>]

Frankly, i don't get it.

/mrg

On Apr 2, 2008, at 3:00 PM, Kathryn Huxtable wrote:

> We didn't get a chance to talk about this during the conference call  
> today, but I wanted to get some more input.
>
> Cornell has suggested an option for storing group memberships in  
> LDAP wherein the memberships would be stored as two-tuples, rather  
> as they are in the database. Cornell has their own attributes for  
> this, but I think we could just use eduMember.
>
> So, e.g. if there's a user in the example source, gmettes, who is a  
> member of the group example:admin:it:staff, there would be an entry  
> in a branch of LDAP of the form:
>
>         cn: example-gmettes-example:admin:it:staff
>         hasMember: uid=gmettes, ou=people, dc=example, dc=edu
>         isMemberOf: example:admin:it:staff
>
> This would create as many objects in this branch of LDAP as there  
> are membership tuples, which could get large, but the individual  
> objects stay very small. It shouldn't complicate or increase the  
> size of the indices at all. The "cn" attribute needs to be  
> constructed of the unique attributes of the tuple to avoid collisions.
>
> This would be an advantage if, as Cornell does, you have a group  
> with more than 100,000 members. It scales very well provided that  
> your LDAP implementation has no silly object limit. (I think Sun  
> Directory server's licensing does have such a limit, but it's not a  
> software limit. Does anyone know about Oracle's Sleepycat  
> implementation, which is used by both Sun and OpenLDAP? Does it  
> perform badly if there are Avogadro's Number of objects (not  
> literally, of course)?)
>
> On the other hand, it's possible that off the self applications  
> won't deal with this.
>
> Personally, I prefer memberships to groups, but which is used at my  
> former institution was conditioned by what application was being  
> used and what its requirements were.
>
> What do people think?
>
> -K