minfrin commented on PR #9: URL: https://github.com/apache/serf/pull/9#issuecomment-3025040959
> Serf is asynchronous, and one serf-context can juggle multiple connections. You need a callback if you want to have a hope in hell of keeping all this straight on the error-reporting side. > > That said, however: the callback doesn't know which connection a given error belongs to. That could be a problem. typical case would be a context with one SSL connection to a server and one connection to an OCSP responder that validates the server cert. It'd be strange if, e.g., OCSP connection errors were reported against a Subversion server. > > OK, OCSP connections shouldn't use SSL. Which brings up the point: why would this callback only be used to report SSL errors, when there can be other kinds of error descriptions available for other connection types, and they, too, can't know what actually happened. Options are limited inside serf. The two places where errors are generated are https://github.com/apache/serf/blob/trunk/buckets/ssl_buckets.c#L1538 and https://github.com/apache/serf/blob/trunk/buckets/ssl_buckets.c#L1054, and the only context that is available at these locations are serf_ssl_context_t. This isn't a crisis though. At a future date, we could add an error callback tied to a connection, and let the caller decide what scope of errors they want. In other words, we don't need to delay providing error messages today in the hope of being perfect in the future. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@serf.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
