On 23/06/2012 00:29, Danny Coward wrote:
> Issues covered in v002
Glad to see it has moved to a more realistic package. How sure are you
that this is where it will end up?
> * Message representation: The API presents messages as String,
> byte[] and Iterators thereof. No nio classes, no IO streams. The goal
> of this approach was to allow buffered messages (for convenience) and
> chunked messages (for efficiency) without limiting the implementation
> choices IO/NIO/combination of implementors of the API.
I agree with Scott and Remy on the Stream / Iterable etc. issues.
> * Connection modes: Though web socket provides no guarantee of
> delivery, the API adds async send modes: the point of completion of
> the send being when the message has been completely transmitted (if
> not necessarily received).
No issues with the concept of async send. Need to think about the
details. Still not at all convinced by the need to handle objects.
> * The API assumes Pings and Pongs are implementation artifacts, but
> not of concern to application developers. So they don't appear.
The ping may include application data so it needs to be visible to the
application.
> * The API doesn't expose web socket data framing, though a chunked
> approach to message processing is exposed. So implementations get to
> choose how to they want to relate the two.
Section 5.4 of RFC 6455 states that frames may have semantic meaning for
extensions. Therefore, frames need to be exposed - at least to the part
of the API that handles extensions.
This approach may also cause issues with sub-protocol support.
My gut feeling right now is the chunking that is being used in the API
currently belongs further up the stack in the application and/or
frameworks that sit on top of this API.
> * The server configuration assumes a simple programmatic mapping to
> URI. There's a range of possibilities, from static configuration to
> more dynamic schemes like in Grizzly. The API hasn't changed since
> v001 in this regard.
>
> * There are some simple annotations in this API that map POJOs into
> Endpoint objects.
Great :( Yet more annotations the container is going to have to scan for
on start-up. I'm not a fan of this approach at all.
> * The API adds session timeouts, and limits on message buffer sizes.
> What's missing ?
Extension support.
Sub-protocol support.
Streams.
Not sure about Endpoint.handleError(). Any problem will either be at the
protocol level in which case the connection will be closed with a close
reason that hasClosed should have access to or it is at the application
level in which case the developer already has an opportunity to handle
it since they threw it.
> * Handshake: the API assumes the developer has minimal knowledge of
> the details of the handshake process, save for the basic elements of
> the URI, optional Origin check, subprotocol preferences. What's
> missing ?
I'm already seeing requests for pretty much everything available on the
HttpServletRequest object. The general indication so far is that the WS
API needs to be fairly low-level with the 'convenience' stuff left to
the higher-level frameworks.
Mark