Hi Oleg, >>I've had some time to relax and think about connections. >>As a result, I would like to sum up what I think you are >>trying to achieve. Please have a look through it and >>correct me where I got you wrong... >> [...] > > Precisely.
Ok. Sorry for being so slow on the uptake. I got on the wrong track when we discussed "turning the connection into a container". The idea of my patch for HTTPCORE-8 was to keep the full functionality and just split the responsibilities between the connection object and the operator. I'm fine with the new design. Let's do it. Axe the open(...) method, and getTargetHost() along with it. But this shift of a rather basic responsibility - opening connections - makes me feel even stronger that HttpConn should be released independently from HttpClient. No objections against initial development there, of course. We already had that discussion. > I am trying to keep HttpCore as a minimalistic, transport agnostic > protocol layer, that is usable with classic I/O sockets, NIO channels, > abstract I/O transports such as MINA and what not. The job of HttpCore > should be in my opinion to ensure RFC 2616 compliant serialization and > deserialization of HTTP messages. The one thing we can't help is that it uses streams. But there's no point in defining yet another I/O abstraction to be mapped to streams and channels. > ConnectionReuseStrategy is not really needed for the client side. It is > a must for the server side HttpService, though. It is used on the server > side to determine whether a connection can be used for subsequent > requests or it should be dropped in order to delimiter the response > content. Ok, then it remains in HttpCore. Should we cancel HTTPCORE-8 and reopen HTTPCORE-11? Redefine the objective of HTTCORE-8? Create a new issue? cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
