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

> > 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,
>   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

View raw message