jsr356-experts@websocket-spec.java.net

[jsr356-experts] Re: Streaming Options

From: Greg Wilkins <gregw_at_intalio.com>
Date: Fri, 13 Jul 2012 11:26:22 +1000

On 13 July 2012 09:25, Danny Coward <danny.coward_at_oracle.com> wrote:
>
> Of the choices in mode (3), I'd probably go for option A). However, I do
> think many developers (me at least, but not Greg!) find the NIO APIs
> awkward, so can see a benefit in the simplicity of option

Actually I'm not a big fan of the NIO APIs(specially the read side,
write side is OKish) - I just raise them as something we should
consider as they are part of the JVM, so developers will be familiar
with them. If we do something different, that's fine, so long as we
know the reasons why.

However, I do like ByteBuffer a lot more than byte[] and I think we
should use the former rather than the later. Arrays can be trivially
wrapped as ByteBuffers, but it is more expensive to convert a
ByteBuffer to an array - so it is best to go with ByteBuffers.

Other than that, I think 3B is currently the least ugly option.

I think that both 1 and 2 can be provided as a layer above 3B.
However I'm fine with providing convenience methods/annotations that
do that wrapping for the application. This means that we will need to
be able to inject more configuration (eg maximum size of a message to
be aggregated) and will have to decide if such configuration belongs
in the annotation (I think not - but others like that style).

cheers




--
Greg Wilkins <gregw_at_intalio.com>
www.webtide.com
Developer advice, services and support
from the Jetty & CometD experts.