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
>