Hi Mark, all,
Thanks for the thorough feedback - pls see inline:-
On 6/25/12 11:44 AM, Mark Thomas wrote:
> 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?
Its the package we indicated in the JSR proposal, so its ours for the
taking I think.
>> * 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.
I reread the section on ping/pongs in RFC6455 and yes I agree. It looks
like we'll need API to send pings at will and listen for returning pongs
(sec 5.5.2). It looks like we will need API to send pongs "as a
unidirectional heartbeat" (sec 5.5.3), but perhaps we'll want the
implementation to handle the sending of pongs as a response to pings
since an endpoint is required to respond to a ping with a pong
containing the same app data (sec 5.5.2), rather than requiring
developers to implement the same code in every 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.
Fair point: From the description of the extension mechanism and the mux
and deflate examples, it looks like extensions are somewhat orthogonal
to applications: so we could expose a view of the incoming/outgoing
websocket messages so that developers could build websocket extensions
that 're-frame' the messages. A kind of filtering mechanism that
operates under the application API, and a web socket framing API that it
uses.
>> * 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.
What more do you think we should be thinking about to support
sub-protocols ? We have the necessary information available for the
handshake. Perhaps we should be looking at how to express a subprotocol
in the API as more than just a name ?
> 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.
Do you have a couple pointers to those requests ?
Thanks,
- Danny
> Mark
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation