Repository navigation
Remove Concept of Multiple Protocols within HTTP #266
Description
Expected
We by default use the HTTP protocol for CloudEvents.
We do not need to specify if the CloudEvent module accepts only binary or only structured events.
Actual
We specify the protocol in the Receiver constructor. Not sure why.
Seems overly complicated.
https://github.com/cloudevents/sdk-javascript/blob/master/src/transport/receiver.ts#L40
https://github.com/cloudevents/sdk-javascript/blob/master/src/transport/protocols.ts
Activity
grant commentedon Jul 23, 2020
I would assume the Receiver to only have static methods in the first place and not be an object.
Why would an application want to have to manage multiple CloudEvent receivers rather than static receivers?
grant commentedon Jul 23, 2020
This would greatly simplify a lof of the extra logic I see in the module.
We can always add in protocols later, but I suggest removing it for now.
lance commentedon Jul 23, 2020
I actually have tentative requirements for MQTT, AMQP and/or Kafka and that's why
Receiveroptionally accepts a protocol. I can see an argument to be made for makingaccept()a static method onRequestor even just a standalone function. This would mean that we would need to add a third, optional protocol parameter toaccept().grant commentedon Jul 23, 2020
I'm fine having an optional parameter to
accept()rather than 100 dangling CloudEvent acceptor objects in my code.I know that is a stretch, but I'd really like it to be static, or at least have the option of being static.
With CloudEvents, things are fully-encapsulating and stateless, so the less state we can have, the better.
Happy to keep the protocol list and have TODOs for those other protocols, especially if you might have requirements for them.
lib: change Receiver#accept() to be static Receiver.accept
lib: change Receiver#accept() to be static Receiver.accept (#271)