WebSockets protocol binding

[slinkydeveloper]

Signed-off-by: Francesco Guardiani francescoguard@gmail.com

Fix #693

This PR adds a WebSockets protocol binding. The big 2 things this spec defines are:

• Events are sent serialized in websocket messages, using an event format agreed during the handshake.
• How to agree on the event format. tl;dr we just use subprotocols defining a mapping between websockets subprotocols and event formats

Sample implementation

I tested this protocol binding hacking the sdk-javascript sample here: https://github.com/cloudevents/sdk-javascript/tree/eca43d907468dd07d9f291bb56f95f658f4b3c40/examples/websocket. In order to implement the binding, i just edited the sample adding the logic for the subprotocols. On client side:

const ws = new WebSocket("ws://localhost:8080", ["json.cloudevents", "avro.cloudevents"]);

Which roughly translates to open a new websocket and tell the server that I support both json and avro serialized cloudevents.

On server side:

const wss = new WebSocket.Server({ 
  port: 8080,
  handleProtocols: (protocols, req) => {
    if (protocols.includes("application/cloudevents+json")) {
      return "application/cloudevents+json";
    }
    return false
  }
});

Which translates to tell the client I only support json and during the stream I'll always use json anyway.

The rest of the code is exactly the same as is now

[clemensv]

After looking at the W3C interface again, it appears that using a subprotocol that includes the event format is indeed the best option we have, even though I still find that iffy.

OneM2M seems to have established a precedent in the IANA registry. I would switch the names to "cloudevents.*". We should reach out to IANA and register at least "cloudevents.json", "cloudevents.avro", "cloudevents.protobuf", and "cloudevents.cbor".

What's missing for the subprotocol definitions is whether the subprotocol is using binary or text frames. I think we will want to default to use text frames for JSON, but binary frames for Avro and Proto.

[slinkydeveloper]

What's missing for the subprotocol definitions is whether the subprotocol is using binary or text frames. I think we will want to default to use text frames for JSON, but binary frames for Avro and Proto.

Should we define it in this table?

[slinkydeveloper]

check it out now

[tweing]

... WebSocket message just contains a CloudEvent ...

Is the JSON Batch Format supported as well? If yes, the sentence would need to be slightly adapted.

[slinkydeveloper]

Is there a use case where you would send json batch over WS?

[tweing]

I don't have a use case and honestly I don't like it. Nevertheless since you are referring to the json format, it might be worth mentioning explicitly that it shall not be supported.

[slinkydeveloper]

Check it out now

[slinkydeveloper]

fc577f9

[tweing]

fine with me - no objections (sorry- can't make it for the meeting on 08-Oct-2020)

[slinkydeveloper]

Rebased and fixed README

[duglin]

Approved on the 10/8 call