arturobernalg commented on PR #815: URL: https://github.com/apache/httpcomponents-client/pull/815#issuecomment-4311350820
> We'd be crossing a Rubicon by exposing support for a platform-specific IO primitive via JNI. I don't think we've done that before. I'd rather have a story for improved custom transport support, which I think would be more sustainable than threading through yet more special cases. `docker-java` implemented both UDS and named pipe transports via `DetachedSocketFactory`, and the main issue with that approach is that it requires the use of internal/experimental APIs; we would solve more problems by stabilizing that extension point, and offering a similar one in the async client (the `java.io.Socket` API is itself legacy). > > If we were to implement this as a special case/first-class feature, I'd like to consider doing it on top of the Unix domain socket support. As far as I can tell, the named pipe support in `docker-java` is a legacy feature and an obsolete workaround for the lack of UDS support in Windows. It might be reasonable to add anyway, but it's not obvious that there's a lot of demand for it. The real issue here is not named pipes per se, but whether HttpClient should grow another transport-specific request option. I used Unix domain socket support as the closest existing precedent, but a generic transport extension point for both classic and async clients would be cleaner. I am happy to rework the proposal in that direction if everyone is agree. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
