websocket-spec
  1. websocket-spec
  2. WEBSOCKET_SPEC-122

Behaviour of onMessage(some mutable object) not defined

    Details

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

      Description

      The specification does not define the scope of validity for objects passed to message handling methods. Is the object only valid for the duration of the method or for all time?

        Activity

        Hide
        dannycoward added a comment -

        Hey Mark : Which objects in particular ?

        Session - I think is well-scoped: the object is valid as long as the connection is open
        Config - valid as long as the endpoint instance is around

        Perhaps you mean some of the various (mutable) message objects ?

        Do you want the container to be able to reuse a ByteBuffer once the onMessage has been completed ? And so require the developer to consume the message within the onMessage(), and discourage them referencing the ByteBuffer outside the scope of that call ?

        Show
        dannycoward added a comment - Hey Mark : Which objects in particular ? Session - I think is well-scoped: the object is valid as long as the connection is open Config - valid as long as the endpoint instance is around Perhaps you mean some of the various (mutable) message objects ? Do you want the container to be able to reuse a ByteBuffer once the onMessage has been completed ? And so require the developer to consume the message within the onMessage(), and discourage them referencing the ByteBuffer outside the scope of that call ?
        Hide
        markt_asf added a comment -

        I do mean the various message objects.

        I have no strong preference for how the validity is scoped.

        If the scope is limited to within the onMessage() call then we'll almost certainly have to add some form of protection to stop developers using the objects outside of that scope (although that is more an implementation concern than a spec one). Personally, I have a slight preference for this but would be happy with a "here is the object, do what you like with it" approach as well.

        I am far more concerned that the scope of validity of these objects is clearly defined than what the scope actually is.

        Show
        markt_asf added a comment - I do mean the various message objects. I have no strong preference for how the validity is scoped. If the scope is limited to within the onMessage() call then we'll almost certainly have to add some form of protection to stop developers using the objects outside of that scope (although that is more an implementation concern than a spec one). Personally, I have a slight preference for this but would be happy with a "here is the object, do what you like with it" approach as well. I am far more concerned that the scope of validity of these objects is clearly defined than what the scope actually is.
        Hide
        dannycoward added a comment -

        OK I understand.

        I think it'd be more convenient for developers to be able to use these objects however they want, put them in hashtables, variables etc. So I think I'd vote for it that way.

        Let's see if anyone else has opinions on the eg.

        Show
        dannycoward added a comment - OK I understand. I think it'd be more convenient for developers to be able to use these objects however they want, put them in hashtables, variables etc. So I think I'd vote for it that way. Let's see if anyone else has opinions on the eg.
        Hide
        dannycoward added a comment -

        OK I think you and Scott have persuaded me: Reader/InputStream/ByteBuffers should not be references outside the scope of the onMessage callbacks.

        Show
        dannycoward added a comment - OK I think you and Scott have persuaded me: Reader/InputStream/ByteBuffers should not be references outside the scope of the onMessage callbacks.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: