hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [jira] Commented: (HTTPCLIENT-258) RFE: Implement HTTP 1.1 Pipelining
Date Thu, 08 Feb 2007 18:11:25 GMT
On Thu, 2007-02-08 at 18:30 +0100, Roland Weber wrote: 
> Hi Oleg,
> > I still do not see how HttpCore NIO attempts to subsume the
> > responsibilities of HttpConn and HttpAsync since both modules are
> > currently based on blocking I/O model.
> Maybe I did not find the appropriate words. I was talking about
> abstract responsibilities, not about implementation techniques.
> Since we've thrown Connection.open() out of HttpCore, I see the
> abstract responsibilities of HttpConn as:
>  - open connections
>  - tunnel/layer SSL
>  - manage connections for re-use
>  - enforce connection limits
> Currently there are only blocking interfaces and implementations
> (if any), which doesn't mean we couldn't put NIO interfaces and
> implementations for these _responsibilites_ there as well. If we
> would find an elegant way of separating NIO-core from NIO-conn
> functionality.
> We never discussed the exact scope of HttpAsync, and I kept on
> emphasizing that the _initial_ implementations would be based
> on blocking IO, because I don't know how to implement others.
> That doesn't mean there should not be non-blocking dispatchers.
> There should be. I just can't implement them, in particular not
> until I've figured out much more about the dispatching problem.
> The dispatching is what I consider the focus of HttpAsync in it's
> present form, with some background worker thread stuff thrown in
> as an implementation detail, because I'd need those to make it
> work with blocking IO.
> To me, it looks as if we're making a very nice split of responsi-
> bilites into Core, Conn, and others for the blocking implementation,
> while the NIO implementation just pushes everything into one module.
> The part that concerns me most about this is that the NIO module
> is in HttpCore. So we have a module HttpCore-main which can do
> very little without other modules, and a module HttpCore-NIO that
> does almost everything by itself.


My position remains the same. Let us start _somewhere_ and get something
that actually _works_. Once we have _something_ working, it is easier to
observe commonalities in code and move components to a better home.

I have worked extensively with both models and am very skeptical we can
have a connection management abstraction that works reasonably well with
both blocking and non-blocking I/O. NIO implies a totally different way
of thinking, which does not mix well with APIs built around the classic
I/O model. I am open to having HttpConn NIO at some point, but
respectfully remain skeptical about the possibility of HttpConn being a
unifying API for both blocking and non-blocking connection management.

> > Yes, one can use NIO to access file system objects but currently all
> > file system bound operations are _blocking_.
> Oh I see. Blocking non-blocking. A fake.
> > This is my personal vision of the HttpComponents stacks:
> > 
> > (1) Blocking HTTP (mainstream)
> > HttpClient
> > HttpConn, HttpCookie, HttpAuth
> > HttpCore
> > 
> > (2) Non-blocking HTTP (covers special use cases)
> > HttpAsync, HttpCookie, HttpAuth
> > HttpCore-NIO
> > HttpCore
> A traditional IO implementation of HttpAsync will make use of HttpConn.
> Probably not the connection managers there, but the connection
> interfaces and implementations, operators, and the auto-close logic.
> I'd also try to re-use the Http[Method]Director logic from HttpClient.
> A NIO implementation of HttpAsync might look much like current HttpNIO
> at the backend, while adding the auto-close logic, Http[Method]Director
> and application notification callbacks at the frontend.

I do not want to steer you in any particular direction, but personally
tend to think of HttpAsync as HttpClient on top of HttpCore NIO. I would
very much welcome HttpAsync dropping blocking I/O stuff altogether and
concentrating on the non-blocking I/O model, which seems to fit better
its stated goals.



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

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

View raw message