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 On Mon, Jun 30, 2025 at 3:34 AM Graham Leggett <minf...@sharp.fm.invalid> wrote: > On 29 Jun 2025, at 11:45, Branko Čibej <br...@apache.org> wrote: > > >> I pulled apart svn, and the svn_error_t structure has a nested > characteristic that makes it perfect for adding extra detail where extra > detail is needed. > > > > Yup. It's a stack of errors, and/or tracing messages. > > > >> Over the next few days I hope to have something that works. > > > > Did you intend to add something svn_error_t/stack-like to Serf, or do > this some other way? I know Serf uses bitmasks, but that seems quite > limited. > > My gut feel was a callback of some kind. > > "If you care, I (serf) have called you (svn) with a string containing > details of an underlying error, do with it what you will". > > Neither serf nor svn has to attach any underlying significance to the > string, it's just extra detail. > > Regards, > Graham > -- > >
