httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: dav_new_error_*() and errno, revisit before 2.4 GA
Date Thu, 12 Nov 2009 03:06:16 GMT
On Wed, Nov 11, 2009 at 20:09, Jeff Trawick <trawick@gmail.com> wrote:
> On Wed, Nov 11, 2009 at 6:58 PM, Greg Stein <gstein@gmail.com> wrote:
>> On Wed, Nov 11, 2009 at 17:11, Jeff Trawick <trawick@gmail.com> wrote:
>>> At present, whatever was in errno at the time the dav_error {} was
>>> created is treated as an apr_status_t by ap_log_rerror().
>>>
>>> http://mail-archives.apache.org/mod_mbox/httpd-dev/200211.mbox/%3C20021101033848.B29006@lyra.org%3E
>>>
>>> dav_error {} should have an apr_status_t field instead of an errno
>>> field; functions which create a dav_error should have an apr_status_t
>>> parameter.
>>>
>>> If there's no direct apr_status_t representation of the error, the
>>> caller will have to decide what to do (no magic portable solution
>>> AFAIK, but no worse than today).
>>>
>>> Concerns?
>>
>> dav_error was designed during the 1.3 series. APR wasn't even being
>> discussed. So yeah... there is definitely a disconnect from "then" to
>> "now".
>>
>> I'd be quite supportive of changing that, though (strictly speaking)
>> that is probably an API change.
>
> well, yes it is an API change ;)  I think the issue is whether or not
> you in the DAV community want to push it on your third-party
> colleagues.
>
> A third-party mod could define something like this for compatibility:
>
> #if AP_MODULE_MAGIC_AT_LEAST(xxx,y)
> #define foo_dav_new_error(p, stat, errid, rv, desc) \
>    dav_new_error(p, stat, errid, rv, desc)
> #else
> #define foo_dav_new_error(p, stat, errid, rv, desc) \
>  (errno = (rv),                                   \
>   dav_new_error(p, stat, errid, desc))
> #endif
>
> and go ahead and change its code to pass in an apr_status_t.
>
> If it is too ugly to force this on third-party modules, we'll need to
> add new APIs and use those ourselves, as it is too ugly for us to keep
> mismanaging the error codes.

I have no opinion in this space. I'm very much out of touch nowadays
with the mod_dav users/community. The one particular user of mod_dav
that I'm concerned with is mod_dav_svn, and *that* is about to become
an Apache project :-)

svn can certainly use that macro. "You" get to measure the disruption
to other API users of Apache.

In fact, we floated the idea of whether mod_dav_svn can/should be
transferred over to httpd, rather than maintained as part of svn.
Total random comment, but a couple people went "hmm...." It would be
kinda neat for any Apache server to have built-in support for svn :-)
(and would solve a bunch of versioning combinatorics for svn...)

Cheers,
-g

Mime
View raw message