On 20/04/2012 23:29, Danny Coward wrote:
> Hello experts,
>
> Before we get to APIs and all that, I want to spend a little time
> talking about the high level requirements of the JSR. These were more or
> less laid out in the JSR itself, so that's always a good place to check
> back on as we get deeper into this.
>
> But I've laid them out again (attached document), together with the
> deployment settings, and a short description of an example application
> and how it all works that uses the output of the JSR.
>
> This is intended to surface high level issues, and is mostly a vehicle
> to see how we collectively see this working.
>
> So, please feel free to post me your thoughts/suggestions/random issues
> this brings up - either to the list or just to me as you prefer.
What is the relationship between this JSR and the various WebSocket
protocol versions? My initial thoughts are align the API with the
features available in RFC6455 with implementers free to support
additional (earlier) versions if they wish. I haven't looked closely
enough at the various earlier versions to see what features are
available to determine how feasible this might be.
Given the requirement "Define an API that can be implemented atop any
Servlet 3.1 container" that may or may not imply that a JSR 356
implementation in a Java EE Web container will be on top of the Servlet
3.1 API. I think it would be good to clarify this one way or the other
so users know for sure if they can rely (or not) on Servlet 3.1 features
as part of their WebSocket application. (I have no idea how likely this
may be or what those features might be - just looking for ambiguities
and trying to clear them up early).
Mark