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

        dannycoward created issue -
        dannycoward made changes -
        Field Original Value New Value
        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.
        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.

        Currently I am thinking the the client API does not support publishing endpoints, and 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.
        dannycoward made changes -
        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.

        Currently I am thinking the the client API does not support publishing endpoints, and 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.
        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.

        dannycoward made changes -
        Due Date 2012-11-16 00:00:00.0
        dannycoward made changes -
        Due Date 2012-11-16 00:00:00.0 2012-12-14 00:00:00.0
        dannycoward made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee dannycoward [ dannycoward ]
        Tags v010
        Resolution Fixed [ 1 ]

          People

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

            Dates

            • Due:
              Created:
              Updated:
              Resolved: