Re: new version of perl-ldap-0.20

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

[snip get now returns array ref or hash ref]

> I am open to suggestions. The only thing I can think of is to revert to
> what was there, allow the hash return in a list context too and add and
> exists method to check if an attribute exists.
> 
> Comments.

I get the feeling (perhaps wrongly) that users of Net::LDAP divide up into
two camps. Those that want/require the level of control which the protocol
provides (access to all options, methods mapping onto single operations,
etc) and those that just want to push and pull data from an LDAP server in
the simplest way possible. Additionally, the same person might place
themselves in either camp depending on the task at hand.

This leads me to think that a high level interface might be useful. Here
are a couple of suggestions on how this might differ from Net::LDAP.

1) The ->new method takes an optional username/password and does a
Net::LDAP->new and a ->bind. Returns object or under if anything fails.

2) In general, methods return true on success, undef or () on failure Yes,
this means you can't tell the difference between 'no data' or 'error'. If
the user doesn't care that's fine (since they may need to handle 'no data'
as an application error anyway). Otherwise we could set $! (or $@?) and/or
provide a 'did an error happen' function.

3) Object destructor does an unbind and closes the socket. (Not sure if
Net::LDAP does this already...probably)


i.e. you could write:

#!/usr/bin/perl -w
use Net::LDAP::Cooked;	# or whatever

my $l = Net::LDAP::Cooked->new( "local.ldap.server" )
	or die( "Can't connect : $!" );
my @staff = $l->list( "ou=staff, o=myorg" )
	or die( "Can't list staff : $!" );
foreach my $person( @staff ) {
	my $name = $person->get( "cn" );
	my $phone = $person->get( "telephoneNumber" );
	print "$name\t$phone\n";
}


The kinds of things going on here would be:

- additional methods which reduce the need to construct arguments to
->search. e.g. ->list, ->read, ->exists

- avoid Net::LDAP::Message returns, give back arrays of
Net::LDAP::Cooked::Entry

- The 'cooked' entries support simple retrieval of scalars. If attr is
multi-valued simply give back first. Provide ->get_all() get an array of
all values back.


So, is this something which would be useful to people (or would have been
useful to them when starting with Net::LDAP) or does it just hide too much
from the user and is likely to confuse them?

If this is something worth doing, should we add bloat to Net::LDAP to
support things like this or should we create a wrapper module.

If we create a wrapper module should it live within the Net::LDAP
namespace or somewhere else?

Should it inherit from Net::LDAP and add/override methods or should it be
a seperate object?

regards,

jb