Re: chasing referrals

[John B. <joh...@ne...>]

Clif Harden wrote:

> If you are talking about a referral callback function that the
> user/application defines, and controls when it is taken, then possibly
> you could say that this proposal meets this standard.

OK. Thats fair enough.

> It is quite possible that applications will implement referral-chasing
> functionality in similar code, in this case put the code in a
> "package/module" external to the perl-ldap module.  Then the user can
> decide to use or not to use the code.

Yes. I think this is the nub of the discussion. No one seems opposed to
having code around which could make life easier, but not everyone agrees
where that code should live.

> The speed of the perl-ldap module has become an issue with some
> people. I remmeber several discussions on this list about it.  The
> more we bloat the code the worse this problem is going to become.
> 
> If you can do this with a autoloading function that is compiled only
> when first called, then bloat is less a problem.

It seems to me that there are two reasons why people might not want this
(and other) code in Net::LDAP (please feel free to chip in with your own
reaons if I've not caught them here):

1 - bloat (generally considered bad, although one person's bloat is
another person's feature, obviously)

2 - cleanliness of abstraction (is Net::LDAP an interface to the LDAP
protocol or an API intended to be of use to LDAP using applications?)


We can try to attack (1) with autoloading and extensions etc. (2) seems
more problematic.

I'm pretty much on the fence. All I'd like a framework (within or without
Net::LDAP) where I can find more cool things (LDAP referral following,
complex attribute value handling, multilingual attribute handling, Tk
widgets for syntaxes, whatever) and perhaps help create them.

You could argue that that framework should be CPAN rather than Net::LDAP
and you could well be right.

Where does everybody else stand?


jb