Re: problems with resolving groups (rescursive)

[Jurgen B. <ju...@bo...>]

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