On 25/04/2012 02:08, Greg Wilkins wrote:
> We also have users wanting access to cookies (for their own auth) as
> well as remote and local IP address/port. With session access, we need
> to note that a session lifecycle may be shorter than a websocket
> connection and that it may timeout and be invalidated while the
> websocket connection is still in use. Perhaps there is a need for a
> mechanism to keep the session alive, but my preference is to keep them
> separate.
Tomcat has had requests for all the HTTP headers to be available during
connection set-up.
> Best to make the session available during the connection, but
> then any long term state would need to be kept in a websocket session
> with a different lifecycle to the Http session?
+1.
> I agree that we need to support both modes, plus I think this also
> extends to extensions. Obviously a co-packaged impl would be able to
> provide its own extensions for compression, MUX etc. Likewise and in
> container impl should be able to provide its own common extensions.
> I'm not so sure about mixed modes... do we want to support a container
> websocket implementation with application extensions?
I had imagined that both frameworks and applications may want to provide
their own extensions.
> If so, then we need a standard extension API as well... which could be hard.
> So perhaps an extension API is something for 2.0 and for now only
> extensions supported by the actual impl will be available.
I think it is worth looking at this for 1.0 even if we decide to bump it
to 2.0
> Websockets provides the semantics of sending Strings and byte[] as
> discrete messages - I think we should first focus on supporting that and
> then see if there is an appropriate space to support Object as well or
> if that can be punted to an API wrapper.
I'd much prefer to punt this to a wrapper.
Mark