websocket-spec
  1. websocket-spec
  2. WEBSOCKET_SPEC-25

Define which encoders/decoders are supported by default

    Details

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

      Description

      We should probably look to JAX-RS for the list of default encoders and decoders it would be good to support in the API. For example (this is a subset of what JAX-RS supports):-

      all Java primitive types
      and their class counterparts
      and collections thereof.

      And we will need to define how they are overridden by application provided encoders and decoders.

      Sections 4.1.2 and 4.1.3 will need updating in addition to the javadoc in various places.

        Activity

        Hide
        dannycoward added a comment -

        we've had a suggestion floating around for a while that we'd make the set of platform decoders and encoders 'consistent with JAX-RS'. Its not yet clear to me what that means. JAX-RS 1.1 defines the following list of java objects that can be created from a string (e.g. this is the list from @FormParam, the others are similar:-

        Be a primitive type
        Have a constructor that accepts a single String argument
        Have a static method named valueOf or fromString that accepts a single String argument (see, for example, Integer.valueOf(String))
        Be List<T>, Set<T> or SortedSet<T>, where T satisfies 2 or 3 above. The resulting collection is read-only.

        From this I can see that we could say JSR 356 has to support platform Decoders for 1, 2 and 3.

        We could define Encoders for 1. I don't see a standard encoding for objects of type 2, 3.

        Also, I presume that 4. collections, this means the JAX-RS container parses from a string which uses a well-defined semantic for lists (like form params). We do not have this in web sockets, and I don't think defining list-delimiters for web socket messages that mean a collection of something is our job to do. So I don't see a way we could support 4 either for encoding or decoding.

        So, the proposal for us seems to boil down to supporting 1. primitive types and the boxed versions thereof for encoding and decoding, and supporting 2 and 3 for decoders only.

        Show
        dannycoward added a comment - we've had a suggestion floating around for a while that we'd make the set of platform decoders and encoders 'consistent with JAX-RS'. Its not yet clear to me what that means. JAX-RS 1.1 defines the following list of java objects that can be created from a string (e.g. this is the list from @FormParam, the others are similar:- Be a primitive type Have a constructor that accepts a single String argument Have a static method named valueOf or fromString that accepts a single String argument (see, for example, Integer.valueOf(String)) Be List<T>, Set<T> or SortedSet<T>, where T satisfies 2 or 3 above. The resulting collection is read-only. From this I can see that we could say JSR 356 has to support platform Decoders for 1, 2 and 3. We could define Encoders for 1. I don't see a standard encoding for objects of type 2, 3. Also, I presume that 4. collections, this means the JAX-RS container parses from a string which uses a well-defined semantic for lists (like form params). We do not have this in web sockets, and I don't think defining list-delimiters for web socket messages that mean a collection of something is our job to do. So I don't see a way we could support 4 either for encoding or decoding. So, the proposal for us seems to boil down to supporting 1. primitive types and the boxed versions thereof for encoding and decoding, and supporting 2 and 3 for decoders only.
        Hide
        dannycoward added a comment -

        This has been resolved: Java primitive types for encoders and decoders.

        Show
        dannycoward added a comment - This has been resolved: Java primitive types for encoders and decoders.

          People

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

            Dates

            • Due:
              Created:
              Updated:
              Resolved: