hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpCore] Proxy Support
Date Tue, 22 Aug 2006 17:44:13 GMT
On Mon, 2006-08-21 at 21:43 +0200, Roland Weber wrote:
... 
> 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. The more I
think of it the more I like this approach. The gory details of
initializing a Socket and binding it to a specific connection instance
should be left up to a object factory.

> > The special case is not connection proxying but rather connection
> > tunneling. My first knee-jerk reaction was to put all the tunneling code
> > into a separate super class
> 
> I think inheritance is the problem, not the solution here.
> 

All right. Let's try to do away with inheritance here and move this
logic into an object factory or some such.

> My problem is that I don't want to make HttpAsync dependent on a
> connection manager. If you have a look at the open issues I have
> created for HttpAsync, you'll notice that it needs a completely
> different connection management interface. I've already pushed that
> to a future release, to reduce the bulk of work to a more manageable
> size. In fact, I had a very bad day a few weeks ago when thinking
> about HttpAsync, and pushing connection management to a future
> release was the one thing that helped me get over that mood.
> 
> 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.  

> > My suggestion would be to port MTHCM to the new API, hack up a very
> > simple HttpClient prototype (no cookies, no authentication, no
> > redirects) and see if we end up with some generic aspects that may prove
> > useful in HttpAsync or HttpCore. It may be a little easier to observe
> > commonalities rather than trying to 'guest' them.
> 
> Do we need MTHCM for the proxy part?
> 

Probably not, but the MTHCM represents a real-life use case for us,
which we could use to see how well (or badly) the new proxy API fares.

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.

Cheers,

Oleg

> cheers,
>   Roland
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Mime
View raw message