Re: problems with resolving groups (rescursive)

[Mark W. <mew...@un...>]

I'm all for this :). I think probably it's better to make it a subclass of
Net::LDAP::Util like Net::LDAP::Util::GroupSearch or perhaps a method of
util.

Mark

On Mon, 9 Oct 2000, Jurgen Botz wrote:

> =?iso-8859-1?Q?Bj=F6rn_Nilsson_=28QDT=29?= wrote:
> > I'm trying to modify the printMembers.pl script (which is included in the
> > Example subdir of the distribution of the LDAP module) to suit my needs. My
> > problem is that the script doesn't resolve the sublists at all, or that it
> > just resolve the first member of a sublist. What I want is to get each and
> > every members (person) attributes to insert them into another database,
> > grouped by the mailinglist in question.
> 
> 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.
> 
> 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'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.)
> 
> - Jürgen Botz
> 
> 
> 
> 
> 
>