I can look into the svn parts once you deal with the serf parts.
Greg Stein wrote on Wed, May 11, 2011 at 15:35:19 -0400: > On May 11, 2011 2:05 PM, "C. Michael Pilato" <cmpil...@collab.net> wrote: > > > > On 05/11/2011 12:00 PM, Daniel Shahaf wrote: > >... > > > > > > When wrapping apr_status_t's returned by serf, shouldn't we decorate > > > them in some way so that code that interprets them knows to look them up > > > in serf.h:SERF_ERROR_* rather than in svn_error_codes.h ? > > > > > > Not sure, perhaps a wrapper err->apr_err link that signals to > > > subr/error.c to call into serf to stringify the child link...? > > > > I'm actually not sure that Serf even provides a stringification function > at > > all. > > Good idea. I can fix that. > > > svn_error_wrap_apr() will use 'status' as the err->apr_err value, but > > will call APR's stringification function which, I would expect, would just > > drop some generic string in place (since the Serf error code range is > > outside of APR's own). Of course, there's no guarantee that Subversion's > > and Serf's error code ranges won't overlap, > > You have a guarantee :-) > > > only that Serf's and APR's won't > > and that Subversion's and APR's won't. > > > > Perhaps the best short-term solution is to not use svn_error_wrap_apr(), > but > > to introduce svn_error_wrap_serf() instead, which can handle APR error > codes > > as svn_error_wrap_apr() does, but map Serf error codes to something > > Subversion-ish. > > Yup. For now, it can just call svn_error_wrap_apr, but we can update it > after serf exposes a new function. That will necessitate a 0.8 release. > > Cheers, > -g
