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

[Kurt D. Z. <Kurt@OpenLDAP.org>]

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