websocket-spec
  1. websocket-spec
  2. WEBSOCKET_SPEC-47

Add checked exceptions to ClientContainer.connect and ServerContainer.publish methods.

    Details

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

      Description

      Then the user knows about the failure cases.

        Activity

        Hide
        dannycoward added a comment -

        Here's my current thinking, which we will discuss in the expert group.

        MessageHandlers and Decoders

        Principles

        Each message is handled by at most one message handler
        Messages that are unhandled result in calls to onError/@WebSocketError callbacks so developers always know if incoming messages are not handled
        Developer provided decoders are chosen before platform decoders.
        If a decoder fails, the error is delivered and no more decoders are attempted.

        Process

        1. a whole string message arrives

        a) if there is an MessageHandler.AsyncText handler - do not call it
        b) if there is an MessageHandler.CharStream handler - do not call it
        c) if there is a MessageHandler.Text handler handler, call it and stop, using the first developer provided Decoder.TextStream<String> or Decoder.Text<String>, if any.
        d) if there is a MessageHandler.DecodedObject<T>
        then try to find a Decoder.Text<T> or a Decoder.TextStream<T>. Look, in order, through developer provided ones (single list, may contain both Text and TextStream types). Then look through platform provided ones. Use the first match to decode it. If the decode works, call the MessageHandler and stop, if not, call the onError/@WebSocket method with the decode exception and stop. If no decoder is found, the message is unhandled.
        Option: prefer higher level objects to lower level ones. i.e. if there is a decoder for T, and there is a MessageHandler.DecodedObject<T>, and also a MessageHandler.Text, choose the MessageHandler.DecodedObject<T>.

        e) If the message is unhandled, call back on the onError/@WebSocketError method. We may need a new exception type for Unhandledmessages.

        2) a whole binary message arrives: same process as 1).

        3 the first piece of a chunked string message arrives.

        a) if there is an MessageHandler.AsyncText handler - call it repeatedly until all the message has arrived and stop
        b) if there is an MessageHandler.CharStream handler - call it with a Reader linked to the incoming parts, and stop
        c) if there are MessageHandler.Text or MessageHandler.DecodedObject handlers, wait for all the string pieces to arrive, building the whole message as you go (subject to the buffer limit defined on the API). If the buffer limit is exceeded call the onError/@WebSocketError method on the endpoint. Otherwise, using the whole message, jump to the analogous steps for 1c), d) and e).

        4) the first piece of a chinked binary message arrives

        same process as 3) but for binary.

        Show
        dannycoward added a comment - Here's my current thinking, which we will discuss in the expert group. MessageHandlers and Decoders Principles Each message is handled by at most one message handler Messages that are unhandled result in calls to onError/@WebSocketError callbacks so developers always know if incoming messages are not handled Developer provided decoders are chosen before platform decoders. If a decoder fails, the error is delivered and no more decoders are attempted. Process 1. a whole string message arrives a) if there is an MessageHandler.AsyncText handler - do not call it b) if there is an MessageHandler.CharStream handler - do not call it c) if there is a MessageHandler.Text handler handler, call it and stop, using the first developer provided Decoder.TextStream<String> or Decoder.Text<String>, if any. d) if there is a MessageHandler.DecodedObject<T> then try to find a Decoder.Text<T> or a Decoder.TextStream<T>. Look, in order, through developer provided ones (single list, may contain both Text and TextStream types). Then look through platform provided ones. Use the first match to decode it. If the decode works, call the MessageHandler and stop, if not, call the onError/@WebSocket method with the decode exception and stop. If no decoder is found, the message is unhandled. Option: prefer higher level objects to lower level ones. i.e. if there is a decoder for T, and there is a MessageHandler.DecodedObject<T>, and also a MessageHandler.Text, choose the MessageHandler.DecodedObject<T>. e) If the message is unhandled, call back on the onError/@WebSocketError method. We may need a new exception type for Unhandledmessages. 2) a whole binary message arrives: same process as 1). 3 the first piece of a chunked string message arrives. a) if there is an MessageHandler.AsyncText handler - call it repeatedly until all the message has arrived and stop b) if there is an MessageHandler.CharStream handler - call it with a Reader linked to the incoming parts, and stop c) if there are MessageHandler.Text or MessageHandler.DecodedObject handlers, wait for all the string pieces to arrive, building the whole message as you go (subject to the buffer limit defined on the API). If the buffer limit is exceeded call the onError/@WebSocketError method on the endpoint. Otherwise, using the whole message, jump to the analogous steps for 1c), d) and e). 4) the first piece of a chinked binary message arrives same process as 3) but for binary.
        Hide
        dannycoward added a comment -

        This has now been fixed.

        Show
        dannycoward added a comment - This has now been fixed.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: