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 Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions

>>> 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
> have a little more time to review.  Looking forward to seeing the
> Also if anybody else has time to review the current util_ldap
> 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). 
> 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
  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

Where should this be handled?


View raw message