Hi Oleg, >>Then we have to factor out the code to establish the connection >>and turn the connection into a simple container for the socket, >>which is filled from the outside. > > Actually this is something we should seriously consider.
Ok, I'll ponder it for some sleepless nights or such :-) >>Regarding the responsibilities of connections and connection managers, >>my idea was to let the connection decide whether it is pointing to the >>target, and if it does the connection manager (or dispatcher) can ask >>the connection reuse strategy whether to keep it alive or not. Or >>something along that line. > > Maybe this is the right way to go for HttpAsync but I am not sure this > is the case for HttpClient. Can you develop this code inside HttpAsync > first and then we can decide whether it should be moved over to > HttpCore. I don't insist on putting it into the connection, I just want to have it in some place where it's reusable. I'll keep the stuff in HttpAsync by extending some core interface or defining a new one. > Can you look into decoupling the process of establishing a connection > from the HttpClientConnection interface, if you happen to have some > spare cycles left? I am stuck neck deep in my day job and NIO stuff and > will have no time to look at HttpClientConnection until the first cut at > HttpCore NIO extensions is complete. I can't promise this weekend, nor next. I'm on a business trip again next week. I'll keep thinking about it, and will come up with some ideas eventually. But I also want to get a few lines done on HttpAsync, especially now that somebody expressed interest :-) cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
