On 9/15/11 4:49 PM, Greg Wilkins wrote:
> I think websockets should be in scope. But not because servlets are
> implemented by HTTP servers (and WS starts with HTTP), but rather that
> servlets are the core component of application servers.
>
> Servlet containers provide and application scope with classloading,
> authentication, authorisation, data sources, resource injection, life
> cycle assistance, developer assistance etc. etc. etc. All these things
> are just as applicable to WS based webapplications as they are to HTTP
> based webapplications.
>
> SIP on the otherhand, is for distinctly different style of
> application, sufficiently different that it does deserve it's own JSR.
>
>
> On 15 September 2011 18:10, Rajiv Mordani<rajiv.mordani_at_oracle.com> wrote:
>> Support for upgrading protocol to WebSocket
> We could support upgrading in general to an arbitrary protocol
> implemented against the async API we have been discussing.
>
> However, i think that protocols and protocols extensions are exactly
> the kind of services that a container should be providing to an
> application, so I'd much rather see upgrade supported to specific
> protocols (like WebSocket... and eventually SPDY etc.).
>
> Note that this kind of de prioritises the need for an async IO API in
> servlets. The main reason for that was to support some of the
> various comet "hacks" out there. If these are now provided for with a
> standard websocket implementations, then why would we need the async
> IO API?
>
>
>> Support for messaging constructs that WebSocket has in the Servlet API
> Indeed - although the design of the actual API for sending/receiving
> frames and messages probably has a wider scope than just servlets.
> So it would be good to get extra input from other groups interested in
> java implementations of websockets.
>
>> Container requirement to support data framing - not exposed to the user in the servlet API
> Within the websockets WG, it is very strongly expressed that framing
> should have no semantic meaning to the application, and thus should be
> entirely transparent to the application. On the other hand,
> extensions such as MUX and compression have to be framing aware.
>
> Thus I think this suggests that we consider an architecture where
> extensions are implemented by the container (and thus can be frame
> aware), which applications will only see a messaging API that deals
> with complete messages.
>
Data framing seems to be too fine grained for application.
Should we expose the fragment? Or the server give them the whole message?
I think we may like to give them fragment? Any comment?
>> Support for security constraints, authentication and authorization
> WS spec now allows standard authentication mechanisms to be applied to
> the upgrade requests. The challenge now is to convince the browser
> vendors to react to any 401 or 302 responses we might send as a
> result.
I saw that in WS spec, too.
>> Support for exposing the sessions, cookies and other java ee constructs like
>> user transaction etc in a websocket application
> It should be simple to establish the session ID of the upgrade request
> for a WS connection, as browsers should now be sending those cookies
> (and maybe adding session to the URI). The challenge is that we need
> to prevent the session from expiring if all the following traffic is
> WS.
>
>
>
> cheers