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. > 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. > 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. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
