[WEBSOCKET_SPEC-3] Specification needs to distinguish better between client and server functionality Created: 21/Sep/12 Updated: 13/Dec/12 Due: 14/Dec/12 Resolved: 13/Dec/12
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
Currently the API classes and specification do not allow for a very clean separation between
client-only functions (initiating a connection from an endpoint)
We will need the separation so the specification can clearly define the websocket requirements on client and server platforms, and cleanly produce two API bundles - client API and server API.
Currently I am thinking the the client API does not support publishing endpoints and the server API does not support initiating a connection to endpoints. Also that the server API has to be embedded in a Java EE web container. But there may be demand for a 'standalone' server API in which case we may need to look at how to separate the server requirements appropriately. i.e. standalone is not required to inject the HttpSession.
|Comment by Sutanu Ghosh [ 05/Oct/12 ]|
+1 for api usability.
It's logical to separate them since there are differences in how client and server endpoints operate.
|Comment by dannycoward [ 17/Nov/12 ]|
Additional feedback: separate ClientContainer and ServerContainer out of having a common superclass. Ditto Config classes.
|Comment by dannycoward [ 08/Dec/12 ]|
the expert group determined that they would like web socket implementations running in application servers to be able to initiate websocket connections to other servers.
Since this functionality is what we had been referring to as 'client-only' it means that websockets running on a client platform (like a tablet) and websockets running on an application server have this behavior in common.
Only the ability to deploy websocket endpoints that await connections from multiple clients is unique to the server.
Therefore, we just need two packages: one for the common stuff + client functionality, and one for the server only functionality.
javax.websocket for the common stuff
So, for example, JDK 9 might include javax.websocket, but not javax.websocket.server, whereas Java EE 7 will include both javax.websocket and javax.websocket.server.
|Comment by dannycoward [ 13/Dec/12 ]|
Since the server profile includes the ability to initiate connections for peer to peer websockets, the 'client only' package is not needed.
We have now
javax.websocket.* - everything shared between client and server implementations
So Client Side (like desktop applications) will need to use javax.websocket.*.