Re: new version of perl-ldap-0.20

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

On Mon, Aug 14, 2000 at 11:26:25AM +0100, John Berthels wrote:
> 
> [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.

True.

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

IMO, this is bad. I even want to move the connect out of new and into a
separate method so that errors can be returned with more ease.

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

I can see why some people may want this. But I am not sure I like it too much.

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

No it does not. And I am not sure about the unbind, I have had bad experiences
with other modules doing quit on DESTROY. An perl will close the socket
anyway.

> 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 : $!" );

I think this is coming back to having someway, other than inheritance (maybe)
to extend Net::LDAP.

> foreach my $person( @staff ) {
> 	my $name = $person->get( "cn" );
> 	my $phone = $person->get( "telephoneNumber" );

For the ::Entry I would prefer to keep one module and have it work as
expected.

And I think the above it the "expected" behaviour. Which would mean
that get returns a list and we add exists. Then we split out the
extra option code I added into another method, say get_nooptions
which always returns a hashref

> 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

What are ->read and ->exist and called on what object ?

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

I would rather just keep one Entry object.

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

I would prefer to just make get context sensetive.

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

Confusion is one thing that concerns me. Because you teach them one
theng then they have to learn something else if they want to go
beyond its boundaries. I would prefer to make the API as natural/easy
as possible.

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

bloat is something I want to avoid if possible.

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

probably within.

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

What would it gain from being a separate module ? I would say it
should inherit, if we have it at all. I would prefer to get the current
module "fixed" rather than create another module just to provide a different
API.

Graham.