users@websocket-spec.java.net

[jsr356-users] [jsr356-experts] Re: For Review: v002 API and example code

From: Scott Ferguson <ferg_at_caucho.com>
Date: Fri, 22 Jun 2012 18:13:01 -0700

On 06/22/2012 04:29 PM, Danny Coward wrote:
>
> Issues covered in v002
>
> * 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.

Without streams, it's not a serious proposal.

Chunking/framing is a low-level implementation/protocol detail related
to implementation buffering; it's not visible at the API-level. The fact
that the draft introduces an iterator to simulate a stream should by
itself be an indication that something is wrong.

Ask yourself this: is HTTP chunking visible to a servlet? No.

The servlet API has a simple stream interface, and has been extremely
effective.

"Convenience" is properly implemented as a layer on top of an efficient
low-level layer. Not a hodge-podge.

-- Scott

>
> * 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).
>
> * The API assumes Pings and Pongs are implementation artifacts, but
> not of concern to application developers. So they don't appear.
>
> * 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.
>
> * 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.
>
> * The API adds session timeouts, and limits on message buffer sizes.
> What's missing ?
>
> * 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 ?
>
>
> --
> <http://www.oracle.com> *Danny Coward *
> Java EE
> Oracle Corporation
>