websocket-spec
  1. websocket-spec
  2. WEBSOCKET_SPEC-3

Specification needs to distinguish better between client and server functionality

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Sutanu Ghosh added a comment -

        +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

        Show
        Sutanu Ghosh added a comment - +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
        Hide
        dannycoward added a comment -

        Additional feedback: separate ClientContainer and ServerContainer out of having a common superclass. Ditto Config classes.

        Show
        dannycoward added a comment - Additional feedback: separate ClientContainer and ServerContainer out of having a common superclass. Ditto Config classes.
        Hide
        dannycoward added a comment -

        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.

        Show
        dannycoward added a comment - 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.
        Hide
        dannycoward added a comment -

        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.*.

        Show
        dannycoward added a comment - 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.*.

          People

          • Assignee:
            dannycoward
            Reporter:
            dannycoward
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Resolved: