On Tue, 2012-07-03 at 15:59 +0200, Greg Wilkins wrote:
> > Although the base layer shouldn't be an async/chunked API, I'm all for an
> > async/messaging layer written on top of the simple blocking streaming layer,
> > if it's a general solution useful for a large class of applications.
>
> I'm the other way around. Let's get async sorted and then blocking is easy.
> Async will be hard and ugly no matter what, but less so if we don't
> have pre-existing blocking API to work around.
One thing I forgot to consider is that, if running on top of the Servlet
3.1 upgrade, the websocket implementation will have to use the async
mode. So in that case, it is probably better to have its core API being
async, with a blocking stream utility available on the side.
Normally, I wouldn't favor that, since it loses the benefit of the
blocking API being simple and fast (it's only simple), but the
environment is quite specific.
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc