Joe Orton wrote:
On Tue, Jun 20, 2006 at 02:11:37PM -0700, Justin Erenkrantz wrote:
On 6/20/06, david reid <[EMAIL PROTECTED]> wrote:
I'd like to commit this patch which adds an APR_ESSL error to APR. It's
only use will be in the ssl code now in apr-util. Is this the right
place for it?
Since the SSL code lives in apr-util, then I think the error code
definition belongs in apr-util not apr. The way the LDAP errors work
is probably a halfway-decent guide. -- justin
The key to solving this properly is to abstract away the underlying
error codes returned by the toolkit being wrapped - the LDAP code
doesn't do that, it just dumps the LDAP_* errors in a structure (and
hence PR 39529).
If the aim is to actually abstract away the SSL toolkit then you need to
work out exactly what error codes need to be returned and where (i.e.
have a well-defined API), then define new errors in apr-util in the
_USERERR space and map these from the toolkit used. (it's a pity there
wasn't an error code space reserved for apr-util in apr_errno.h; that
would be useful to fix in APR 2.0)
Well.... nothing says the next version is 1.3 :-) Suggestions on a richer
return value API which isn't computationally or storage intensive?
I'd agree that LDAP + SSL are both good examples to start from. Registering
additional error spaces is a good starting point.
