Re: problems with resolving groups (rescursive)

[Graham B. <gb...@po...>]

On Mon, Oct 09, 2000 at 08:25:42AM -0700, Jurgen Botz wrote:
> I have written a bunch of code to resolve all the members of a group, list
> all the groups a person is a member of (memberships), and test for membership
> in a group.  This works for nested groups and "dynamic groups" (groups with
> memberURL attributes).
> 
> I packaged this up as a set of extensions to Net::LDAP by subclassing.  The
> idea is that my functions work like searches but may actually do multiple
> searches to do their work so they return a specialied Net::LDAP::Search
> object.  In other words, you can do this:
> 
>   $result = $ldap->get_members($groupdn, 'attrs' => [ 'cn', 'uid', 'title' ]);
> 
> And $result will contain all the entries of the members with the specifed
> attributes (or all attributes if not specified, just like search).
> 
> The code does some mildly interesting things to be efficient, such as
> aggregating searches for entries under the same base and going to some 
> lengths to avoid having to retrieve the same entry twice... this was
> also the motivation for returning the same kind of object as a search, so
> I don't have a function that retruns a list of the dn's of members and
> then I have to retrieve each member entry again just to get some more
> attributes for it.
> 
> I'm calling this kind of thing a "metasearch".  Ideally metasearches should
> work exactly like normal ones to the consumer, including doing them async,
> but I haven't actually implemented async yet.

There was a package a while ago called LDAPiranah which did a similar
thing. I have several things on my todo list to enable this kind of
extension whithout having to know any internals of Net::LDAP

> I was going to handle async and improve some things before releasing this,
> but if there's sufficient interest I'll see if I can package it up now and
> pass it on.

I normally find that if you write it for async first, then sync comes
very easy. The other way is not so easy.

> I'm also in interested in what people (especially Graham) think about this
> approach to doing complex or semantic searches.  Is subclassing Net::LDAP
> and Net::LDAP::Search the right way to go?  What should I call this thing?
> (right now it's called Eazel::LDAP because I work at Eazel and I wrote it
> for a work-related project.)

Yes. What I have been working on is a way to easily sub-class ::Search etc.

The problem is that they are created from within Net::LDAP itself, so
somehow we need to tell Net::LDAP to create different objects.

I was going down the route that you call a method on the $ldap object
which will return the class needed. But that is not scalable. MAybe
we should add a class method to search() which states the class
to use for the message.

The next taks is to create chain-able messages. So a message is never
done() until all it's sub-messages are done. This should then work
for these kind of searches in an async mode.

Graham.