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) HttpClient HttpConn, HttpCookie, HttpAuth HttpCore (2) Non-blocking HTTP (covers special use cases) HttpAsync, HttpCookie, HttpAuth HttpCore-NIO HttpCore I want to re-iterate: it is just my personal vision. I am very open to alternative views. Oleg > > cheers, > Roland > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
