perl-ldap-dev

method result truth (was: Re: Access problem)

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

On Wed, Jun 05, 2002 at 12:16:21PM +0100, Graham Barr wrote:
> On Wed, Jun 05, 2002 at 03:55:31AM -0700, Murugan K G wrote:
> > Hi  Chris
> >    Thanks for your immediate  response.
> >  I  am binding with LDAP3 only  as 
> > $ldap->bind('admin',password => 'novell', version=>3)
> > or die "Not able to bind";
> 
> bind, like most Net::LDAP methods, will always return true. You need to check
> the ->code method of the object returned.

Does anyone else think that this is such a common problem that we
should try to deal with it ?

We could deal with it by using overload on the message object, such
that on a boolean context it determines if there was an error.

Of course, you then have the issue of how does the library determine
when a result is an error.

Well my thought is that we could allow the user to pass a list
of acceptable result codes. By default LDAP_SUCCESS would always
be an acceptable result code, and compare would allow the TRUE/FALSE
result codes.

We could even make it honor the onerror argument passed to new

Graham.

PS: I have thought about this before and still have an old patch
somewhere that will do this.

Re: method result truth (was: Re: Access problem)

[Kurt D. Z. <Ku...@Op...>]

My thoughts on this is that there should be a clear
distinction between API error information and protocol
result information returned by the server.

The call's return should indicate API success or failure.
Result codes should be handled separately.  Overloading, as
done in the LDAP C API, is a bad thing.

Kurt

At 07:50 AM 2002-06-05, Graham Barr wrote:
>On Wed, Jun 05, 2002 at 12:16:21PM +0100, Graham Barr wrote:
>> On Wed, Jun 05, 2002 at 03:55:31AM -0700, Murugan K G wrote:
>> > Hi  Chris
>> >    Thanks for your immediate  response.
>> >  I  am binding with LDAP3 only  as 
>> > $ldap->bind('admin',password => 'novell', version=>3)
>> > or die "Not able to bind";
>> 
>> bind, like most Net::LDAP methods, will always return true. You need to check
>> the ->code method of the object returned.
>
>Does anyone else think that this is such a common problem that we
>should try to deal with it ?
>
>We could deal with it by using overload on the message object, such
>that on a boolean context it determines if there was an error.
>
>Of course, you then have the issue of how does the library determine
>when a result is an error.
>
>Well my thought is that we could allow the user to pass a list
>of acceptable result codes. By default LDAP_SUCCESS would always
>be an acceptable result code, and compare would allow the TRUE/FALSE
>result codes.
>
>We could even make it honor the onerror argument passed to new
>
>Graham.
>
>PS: I have thought about this before and still have an old patch
>somewhere that will do this.
>
>
>_______________________________________________________________
>
>Don't miss the 2002 Sprint PCS Application Developer's Conference
>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: method result truth (was: Re: Access problem)

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

You have said this many times before, but that is a different issue.

At a high level the user should be able to
ask "was there an error", then they should be able to probe
to determine what the error was. It is at that point they can
distinguish between different types of error.

But there should be one place that returns an error code. Now
if you want to have one code that basically states "go look somewhere
else" then thats fine, but the user should not have to do multiple
checks to determine if there was an error.

IMO, the protocol error codes already handle this with the
LDAP_LOCAL_ERROR code. Its just that Net::LDAP does not provide
any method to determine a "local" error as it does not define any.

Graham.

On Wed, Jun 05, 2002 at 08:01:04AM -0700, Kurt D. Zeilenga wrote:
> My thoughts on this is that there should be a clear
> distinction between API error information and protocol
> result information returned by the server.
> 
> The call's return should indicate API success or failure.
> Result codes should be handled separately.  Overloading, as
> done in the LDAP C API, is a bad thing.
> 
> Kurt
> 
> At 07:50 AM 2002-06-05, Graham Barr wrote:
> >On Wed, Jun 05, 2002 at 12:16:21PM +0100, Graham Barr wrote:
> >> On Wed, Jun 05, 2002 at 03:55:31AM -0700, Murugan K G wrote:
> >> > Hi  Chris
> >> >    Thanks for your immediate  response.
> >> >  I  am binding with LDAP3 only  as 
> >> > $ldap->bind('admin',password => 'novell', version=>3)
> >> > or die "Not able to bind";
> >> 
> >> bind, like most Net::LDAP methods, will always return true. You need to check
> >> the ->code method of the object returned.
> >
> >Does anyone else think that this is such a common problem that we
> >should try to deal with it ?
> >
> >We could deal with it by using overload on the message object, such
> >that on a boolean context it determines if there was an error.
> >
> >Of course, you then have the issue of how does the library determine
> >when a result is an error.
> >
> >Well my thought is that we could allow the user to pass a list
> >of acceptable result codes. By default LDAP_SUCCESS would always
> >be an acceptable result code, and compare would allow the TRUE/FALSE
> >result codes.
> >
> >We could even make it honor the onerror argument passed to new
> >
> >Graham.
> >
> >PS: I have thought about this before and still have an old patch
> >somewhere that will do this.
> >
> >
> >_______________________________________________________________
> >
> >Don't miss the 2002 Sprint PCS Application Developer's Conference
> >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 

Re: method result truth (was: Re: Access problem)

[Kurt D. Z. <Ku...@Op...>]

At 08:35 AM 2002-06-05, Graham Barr wrote:
>You have said this many times before, but that is a different issue.

Well, I might have misunderstood your intent.  It sure sounded
to me that you intended to have ->bind() return dependent
both API condition and protocol result code.

>At a high level the user should be able to
>ask "was there an error", then they should be able to probe
>to determine what the error was. 

I don't view a operation which returns a non-successful
result code as being an API error, and that's the question
I'm interested in asking.  That is, any valid response the
server is successful in terms of the Application/API layer.
I prefer to deal with protocol result codes in the application,
not the API.

As an analogy, when I do a file read(), I expect the
read() to return an error if it failed to read the
bytes from the file.  I don't expect read() to fail
because it returned different bytes than I had expected,
that's an application issue.

Of course, one can make reasonable arguments for other
approaches.  I've said my piece and will leave it at that.

If you do go with an approach which is dependent on both
API conditions and protocol result codes, I suggest you
allow the application not only to say which protocol
codes are to be treated as success/failure, but to allow
the application to have the API treat all results as
either success or all as failure.  (All as success would
provide the behavior I would find useful, all as failure
would be for completeness.)

>IMO, the protocol error codes already handle this with the
>LDAP_LOCAL_ERROR code.

The problem, of course, comes when a (misbehaving) server
returns a protocol code (81-90) reserved for APIs.  I've
seen many cases of this in the real world.  Luckily, the
specification says that in such cases the client is to treat
such as as an unknown error condition.

>Its just that Net::LDAP does not provide
>any method to determine a "local" error as it does not define any.

Good.

Kurt

Re: method result truth (was: Re: Access problem)

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

On Wed, Jun 05, 2002 at 09:04:29AM -0700, Kurt D. Zeilenga wrote:
> At 08:35 AM 2002-06-05, Graham Barr wrote:
> >You have said this many times before, but that is a different issue.
> 
> Well, I might have misunderstood your intent.  It sure sounded
> to me that you intended to have ->bind() return dependent
> both API condition and protocol result code.

Yes I did

> >At a high level the user should be able to
> >ask "was there an error", then they should be able to probe
> >to determine what the error was. 
> 
> I don't view a operation which returns a non-successful
> result code as being an API error, and that's the question
> I'm interested in asking.  That is, any valid response the
> server is successful in terms of the Application/API layer.
> I prefer to deal with protocol result codes in the application,
> not the API.

I think you definition of error is different to my definition of
"failure"

I want the method to return a boolean dependant on the "sucess/failure"
of the operation. That is it returns true only if the complete
operation suceeded, where the error comes from does not matter.

If the user cares, then they use methods to determine what error
caused the failure.

> If you do go with an approach which is dependent on both
> API conditions and protocol result codes, I suggest you
> allow the application not only to say which protocol
> codes are to be treated as success/failure, but to allow
> the application to have the API treat all results as
> either success or all as failure.  (All as success would
> provide the behavior I would find useful, all as failure
> would be for completeness.)

Allowing the "feature" to be turned off would be trivial.

But you could still what you wanted anyway by not using the "onerror"
feature and not using the message object in a boolean context.

I am not raming this down your throught, you will still be able
to do everything. What this does do thought is make the API more
friendly, IMO

> >IMO, the protocol error codes already handle this with the
> >LDAP_LOCAL_ERROR code.
> 
> The problem, of course, comes when a (misbehaving) server
> returns a protocol code (81-90) reserved for APIs.  I've
> seen many cases of this in the real world.  Luckily, the
> specification says that in such cases the client is to treat
> such as as an unknown error condition.

We cannot fix other peoples broken code.

Graham.


> >Its just that Net::LDAP does not provide
> >any method to determine a "local" error as it does not define any.
> 
> Good.
> 
> Kurt
>