apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: apr-util/ldap/ - sink or really swim to 1.0 release?
Date Fri, 30 Jul 2004 21:17:19 GMT
   The LDAP error codes probably shouldn't be mapped to the APR error
namespace.  Maybe the const char **reason should be changed to
apr_ldap_err_t *reason instead.  This structure could hold the native
LDAP error code as well as any other information.  The actual return
code from the function could then be APR_SUCCESS, any other APR_ error
if appropriate or APR_EGENERAL meaning "check the apr_ldap_err_t
structure for more information".

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> Graham Leggett <minfrin@sharp.fm> Friday, July 30, 2004 12:11:57 PM
>>>
Brad Nicholes wrote:

>    I wish I was going to be at LinuxWorld but I guess that means that
I
> have a little more time to review.  Looking forward to seeing the
code. 
> Also if anybody else has time to review the current util_ldap
backport
> proposals, I would like to get that done and into 2.0, otherwise the
> modules remain broken in 2.0 (AFAIK the stuff works great in 2.1). 
We
> might get a little more help on the rest of the LDAP code if what
> already exists really worked.

A question: The LDAP SDK returns error codes.

How should provision be made for them? Should we be mapping them to
APR_ 
  namespace protected codes? If so, how? It seems errorno handling is 
done in apr, not apr-util - but apr doesn't have any knowledge of
LDAP.

Where should this be handled?

Regards,
Graham
--


Mime
View raw message