That's the question, really. I'll dig into it a bit deeper tonight and try to come up with some more formalized thoughts -- I just remember having this nagging feeling while doing the keep-alive that it was only possible to add because the API wasn't frozen. Ideally, it would have been possible (if a little less elegant) even if the API was frozen.
Sam On Thu, Jul 10, 2008 at 5:52 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > On Thu, 2008-07-10 at 17:32 -0400, Sam Berlin wrote: > > ... > >> While adding keep-alive support, I noticed that code-changes that need >> to provide the ClientConnectionManager with more information aren't >> possible without API changes. In the rest of HttpClient's code, >> there's usually an HttpContext being passed around that can hold >> key/value pairs so things can easily be plugged in without requiring >> full-blown API changes. I can't see any way to do this with >> ClientConnectionManager currently. Maybe there should be some Context >> that that uses? Or share the HttpContext itself? This will likely >> become an issue after an API freeze if there's more data we find >> ourselves suddenly wanting. >> >> Sam > > What methods of ClientConnectionManager should take a context as an > additional parameter? > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
