Hi Danny, my comments below..
----- Original Message -----
> From: "Danny Coward" <danny.coward_at_oracle.com>
> To: users_at_websocket-spec.java.net
> Cc: "Rossen Stoyanchev" <rstoyanchev_at_vmware.com>
> Sent: Wednesday, January 16, 2013 8:17:02 PM
> Subject: Re: [jsr356-users] Public draft feedback
> Hi Rossen,
> Thanks for the feedback !
> On 1/16/13 4:03 AM, Rossen Stoyanchev wrote:
> > Hi Danny,
>
> > As previously discussed offline, I have some feedback on the
> > current
> > draft of the spec.
>
> > Programmatic Deployment of Endpoints -- server endpoints are
> > discovered by annotations or by type (via
> > ServerEndpointConfiguration). Applications and frameworks will
> > benefit from having a programmatic way to deploy endpoints. The
> > ServerApplicationConfiguration mechanism is useful but an
> > application may prefer to deploy endpoints directly rather than
> > remove from a list of scanned ones. If the Servlet API can be used
> > as an example, not having such option is similar to Servlets being
> > discovered by type or annotations without the option to deploy them
> > via web.xml or ServletContainerInitializer.
>
> Yes, this was in earlier drafts, but we removed this when we added
> the scanning/ApplicationConfiguration scheme. I agree this would be
> useful for frameworks, though I'm a bit worried about all the
> different modes people might end up wanting. Is a one-at-a-time
> blocking deployment call sufficient do you think ?
I presume you mean something similar to the ServerContainer.publishServer(...) from earlier drafts? If so then yes.
> Endpoint Instances -- it should be possible to deploy endpoint
> instances in addition to endpoint types. I believe this point was
> raised on the user list before. The Tyrus implementation provides it
> as an option, so obviously it's considered useful there. By
> comparison the ServletContext in Servlet 3.0 allows registration of
> Servlets and Filters by instance and by type.
> Yes you are not the only person to ask for this, and thanks for the
> reminder about the servlet model - always good to look across to
> other component models.
> Currently the websocket implementations create a new instance of the
> websocket endpoint per client connection. This provides developers
> with an easy, single threaded model to deal with (unlike servlets).
> So the deploy-by-config class / endpoint class scheme works well for
> that.
> If we define (in addition) deployment of single endpoint instances,
> then I think implementations would need to interpret that as meaning
> 'use the same endpoint instance to handle all events and messages
> from all clients' which is quite a different model. It might be ok
> to have both models, but that would be how deploy by class and
> deploy by instance would be.
Yes an endpoint deployed by type is instantiated per client connection and is stateful while an endpoint deployed as an instance is re-used across client connections and is stateless. Those semantics are understood and to be expected!
> > WebSocket Server Paths -- section 6.4 requires the WebSocket URI
> > space to be relative to a single root. If I understand correctly in
> > Web containers, WebSocket implementations will install a Servlet
> > (or
> > Filter) to handle the upgrade process and all WebSocket URIs will
> > be
> > relative to the mapping of that Servlet?
>
> The idea of 6.4 is that all URIs for websockets in the same web
> application are rooted at the context root of the web application.
> > This seems unnecessarily restrictive. An application may want more
> > freedom in organizing its URI hierarchy according to functionality
> > or to be fully self-contained under its own root (e.g. 3rd party
> > service deployed as a Servlet exposing both REST and WebSocket
> > services). I see the Tyrus implementation currently deploys a
> > Filter
> > at "/*" and gets involved only when there is a matching WebSocket
> > endpoint. That's actually the end result I have in mind -- that
> > endpoints should be deployable at any URI, without requiring a
> > common prefix for WebSockets.
>
> The developer has the freedom under this scheme to put websockets
> anywhere under the URI space of the webserver, with the caveat that
> all the websockets in the same web application will share the same
> root.
> So, basically, its the same scheme as servlets.
Okay thanks for clarifying. I read too much into "websocket root".
> > Request-time Endpoint Deployment -- currently the WebSocket
> > implementation performs the handshake and selects the endpoint. It
> > is not possible for an application or framework to get involved
> > until after the connection has been established.
>
> Maybe I'm misunderstanding here, but by providing a custom
> configuration object, the websocket developer can intercept the
> handshake to inspect/modify the handshake interaction. Such a custom
> configuration object could equally be provided by a framework that
> sits on top of the websocket API, and be selected by the developer.
> For example, the server side developer can subclass
> DefaultServerConfiguration and override modifyHandshake(), (and the
> whole URI mapping scheme if he wants to !).
Yes DefaultServerConfiguration provides options for URI matching and has modifyHandshake. What it doesn't provide is a central entry point for request processing where an application could implement shared functionality for all incoming requests (including WebSockets) prior to delegating to the WebSocket engine or processing the request otherwise. For example an application could call a 3rd party REST API (e.g. oath), get some data from a database or some other store and initialize the endpoint instance providing it with request specific data or configuration it needs. Without that the application would probably have to deploy a Filter (hopefully ordered ahead of the WebSocket runtime's own Filter?). Putting the shared logic in each endpoint or endpoint configuration doesn't seem feasible.
> > An application should be able to initiate the handshake process by
> > delegating to the WebSocket runtime in order to attempt an upgrade
> > while also providing the Endpoint instance (or EndpointFactory) to
> > use directly in case of a successful upgrade.
>
> If I understand what you say, this is like calling
> WebSocketContainer.connectToServer with a custom
> ClientConfigurationObject.
Yes, similar to that although ServerEndpointConfiguration may not be ideally suited. When the application delegates to the WebSocket runtime, it probably matched the URI before delegating, it has access to the request and response (hence no need for modifyHandshake), and it's most natural to provide the endpoint instance possibly via EndpointFactory so it's created only if necessary.
Thanks,
Rossen