On Mon, Jun 30, 2025 at 4:52 PM Greg Stein <gst...@gmail.com> wrote:
> A callback to provide error information? Is that what you're really
> suggesting?
>
> Think of the implications of that. A serf function is called. It runs into
> a problem. It calls back and the app places the additional information ...
> where? Kind of some global thing? Then the serf function returns an error
> code to the app. Then the app says "oh. maybe there is more info. let me go
> look in the global variables"
>
> No. That is terrible dataflow. Please explain what you mean ... something
> other than the nightmare above.
>
> The svn_error_t structure and its functionality exists as a core feature of
> the svn codebase. It is fully-integrated throughout. Serf was not designed
> with that pattern, for better or worse.
>
> Thanks,
> -g
>
I assume you're talking about PR-9 [1].
I agree a callback for error reporting is not an ideal dataflow, but
since, as you point out, Serf was not designed with the pattern used
in the SVN codebase, the only ideal way to fix this is to go back in
time and design it that way from the start. Something tells me that
might not be feasible. :-)
Though this isn't ideal, the benefit to users and administrators is
huge. When there's an error related to network problems, it helps
tremendously to have more specific information than "I'm very sorry,
Dave, I'm afraid I can't do that." [2]
Ostensibly the application (e.g., Subversion) would *not* store error
information in some global. The application does get a chance to set a
callback context ("baton" in the proposed serf_ssl_error_cb_set() in
the PR). So the error would go someplace appropriate that is related
to whatever the application is doing at the time.
Unless anyone has a better way to offer, I think the idea presented
there is worthwhile.
[1] https://github.com/apache/serf/pull/9
[2] https://en.wikipedia.org/wiki/2001:_A_Space_Odyssey
