Hi Oleg, >> 2. attribute in the HttpClient > > I tend to prefer 2. I am strongly not in favor of storing interfaces in > HttpParams. CredentialsProvier was my biggest design blunder in the > HttpClient 3.x days.
I was beginning to wonder where to draw the line between params and context. That's a good distinction. Parameters are for constants only, meaning instances of final classes such as String, Integer, HttpVersion. Except that HttpVersion is not final. So rather non-functional classes, which only _represent_ a value and where the actual instance doesn't matter. The stuff which would be a "valuetype" in IDL. > Why would you want a different connection re-use strategy on a per > request basis in the first place? Good point. The only reason would be to prevent re-use of the connection in specific situations. If the situation is known in advance, it is better to send a "Connection: close" header with the request. If it is determined dynamically, some yet to be defined "abort" method can be used. No need at all for overriding the re-use strategy. >> Should we have a NoConnectionReuseStrategy implementation >> of the interface in HttpCore? This question remains open. thanks, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
