On 10 October 2011 18:49, Remy Maucherat <rmaucher_at_redhat.com> wrote:
> On Sun, 2011-10-09 at 09:43 +1100, Greg Wilkins wrote:
> > I do think that a simple blocking message based API is going to cover
> > the vast majority of use cases and thus I think it should be a first
> > goal to achieve in the API. Then we can consider streams and/or
> > asynchronous WS either later in this spec cycle or in the next, as
> > more evidence of need is collected.
>
> When it is done by another JSR later, I think it will be obvious it
> needs at least scalability parity with HTTP. Especially given the
> protocol goal. So it would really need to do non blocking.
>
If you look at the results we have got with jetty+cometd of HTTP vs
Websockets:
http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/
You will see that we already have gone way beyond scalability parity with
HTTP, even with a blocking API for websockets.