Consider cloud events in relation to MQP payload and interop (W2AT feedback)

[petersilva]

https://github.com/cloudevents/spec

https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/bindings/mqtt-protocol-binding.md

[petersilva]

Raoult Beaudoin (at the W2AT meeting) mentioned possibility of interop or perhaps adoption of cloudevents.
I hadn't encountered them before, but they have bindings to both AMQP and MQTT, so possibly interesting.

[golfvert]

Original email:
After the meeting I had a look at CloudEvents (https://cloudevents.io/). Even if I am often quite skeptical when it comes to pile up multiple level of abstraction before tackling reality (my dumb pragmatism speaking here...), it looks a quite interesting way to describe our "messages".
It could be helpful, if and when in a few years we want to add a new MQP protocol in the loop, for example. Or for interoperabity with Could providers services.
It looks more fit for purpose than using STAC.
At least, considering Tom's comment, it may make sense to look at it and (eventually maybe) discard it for a good reason and not because we missed it.

[petersilva]

at first blush, after reading the spec.

with some semi-farcical points given or taken away, more to illustrate what features are postive or negative and degree... admittedly highly subjective:

• it standardizes a binary payload that is serializable to JSON, but not actually JSON... so it is actually standardizing a binary payload format. similar to Google's protocol buffers and such. -1 readability/debugging, +1 efficiency/throughput
• it has a "Protocol Binding for MQTT" which embeds the opaque messages in MQTT ones. The topic is not considered, not used or included in consideration. and so if CloudEvent is received from an MQTT source, the topic will not be transferred after it is received, if the output channel is something else. -1 no hierachical topics. -1 added layer of embedding (should have value to merit that)
• It has no concept of broker... It is point to point with no concept of intermediaries, which means there is no standard processing to leverage... more like ZeroMQ than a traditional MQP -1 no broker.
• or server-side filtering. It has no concept of hierachical topics. Implementing that would mean application code. It does not leverage such features of MQP, as it needs to work with other technologies that lack it. ( -5 no server-side filtering ?)
• the payload is compact, minimal and similar to MQP spec. It has room for optional fields to make an equivalent representation. +2 for purpose a good match what we are trying to do
• It talks about a maximum message size of 64KB... That's likely too big, but at least there is a limit +1 limited size.
• The thing being announced must be a full URL. -1 we must supply baseURL full (extra bytes) +1 it's what every other payload does.

Overall score is about -4 so far... I think sticking with a pure MQP payload is probably simpler & better as losing server-side filtering is kind of crippling. We could always have an output adaptor for it... but perhaps others' might be more optimistic.

[josusky]

I came to a similar conclusion as @petersilva . It seems to me that CloudEvents layer would add complexity without adding any special benefit. It does not really simplify adding support for other protocols. For AMQP it offers two different serialization methods (added complexity).

[petersilva]

further discussion here: https://github.com/wmo-im/wis2-notification-message