Re: problems with resolving groups (rescursive)

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

On Tue, Oct 10, 2000 at 10:23:21AM -0500, Mark Wilcox wrote:
> 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.

This all comes back to the discussion we had about APIs a long time ago.

For subs which return a message object like the normal methods then sub-class
makes sense. But then how do you use several subclasses, you have to create your
own sub-class which inherits from them all. Thats messy.

What I am considering is a Net::LDAP::Extn (althou thats too close to Extension
so I need a better name). This class will install extras methods into Net::LDAP.
So for example

Net::LDAP::Extn::groupsearch

would define and export a groupsearch method

use Net::LDAP::Extn qw(groupsearch);

will load the module and install the method into Net::LDAP, thus making
it avaliable to all Net::LDAP methods.

Graham.

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