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 16:48:50 GMT
On Thu, 2007-02-08 at 16:56 +0100, Roland Weber wrote:
> Hi Oleg,
> >> All those are things that an HttpDispatcher was supposed to take
> >> care of. HttpCore-NIO (emphasis on _core_) already subsumes
> >> responsibilities of HttpConn, now HttpAsync is to follow.
> > 
> > How come?
> HttpConn: It establishes connections, doesn't it?
> HttpAsync: If you add the queueing.

Hi Roland,

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.

> > Oh my god! C'mon, Roland. Do you know how much of my time and hard work
> > I put into HttpClient 3 is going to get thrown into the rubbish bin?
> I grant you that :-( On the positive side, consider how many people
> will keep using HC 3.x for years to come and refuse to switch to 4...
> > I said this before, I'll say it again: NIO makes no frigging sense for
> > pure clients or pure servers. The complexity of NIO is simply not worth
> > it. Blocking HTTP with a reasonable threading strategy will always
> > outperform non-blocking one at a fraction of complexity of the latter.  
> Well, then let me rephrase the suggestion without the frustration:
> HttpClient has become an interface, and we can have different
> implementations. If much of the functionality is already there
> in NIO, we have the option of implementing HttpClient on top of that.
> The user won't see anything of the complexity. If it allows us to
> come out with a first implementation sooner, it could be worth a shot.

I am not sure I like the idea of HttpClient being an interface. I also
do not see a point in developing a NIO based equivalent of HttpClient
3.x. It should be possible to easily assemble one using HttpCore NIO,
HttpCookie and HttpAuth, if one feels like doing so, but as I said
before, I see no benefits in NIO of what so ever for pure HTTP clients.

> > NIO makes sense for middle-tier services like message mediators and
> > reverse proxies. 
> Because they are routing through incoming messages and don't
> have to deal with user authentication and such things? Because
> they don't call blocking front-end and back-end services?
> I don't know enough of NIO to understand the tradeoff. A simple
> file server can access the file system through NIO, too.

Yes, one can use NIO to access file system objects but currently all
file system bound operations are _blocking_.

This is my personal vision of the HttpComponents stacks:

(1) Blocking HTTP (mainstream)
HttpConn, HttpCookie, HttpAuth

(2) Non-blocking HTTP (covers special use cases)
HttpAsync, HttpCookie, HttpAuth

I want to re-iterate: it is just my personal vision. I am very open to
alternative views.


> 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