[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

Status: Resolved
Project: websocket-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: dannycoward Assignee: dannycoward
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: v010


Currently the API classes and specification do not allow for a very clean separation between

client-only functions (initiating a connection from an endpoint)
server-only functions (publishing an endpoint to accept incoming connections)
common functions: bi-directional messaging over an established connection.

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.

I suggest:
javax.net.websocket - all common stuff
javax.net.websocket.client - client only
javax.net.websocket.server - server only

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.

Something like

javax.websocket for the common stuff
javax.websocket.server for the server-only 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
javax.websocket.server.* everything that only makes sense in a server implementation.

So Client Side (like desktop applications) will need to use javax.websocket.*.
Server Side (like web applications) will need to use both javax.websocket.* and javax.websocket.server.*.

Generated at Fri Feb 24 11:28:52 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.