WIP - Draft for possible MQTT property bag implementation.

alaendle commented 4 years ago

As tried to discuss on the mailing list: https://groups.google.com/d/msg/rabbitmq-users/M5rGuvnhyZY/xDWBcOCaFwAJ

Proposed Changes

I try to pick up on the tiresome topic of lack of metadata support in MQTT 3.1.1.

Inspired by the way Microsoft handles this in its IoT Edge (please take a look at https://docs.microsoft.com/en-US/azure/iot-hub/iot-hub-mqtt-support#sending-device-to-cloud -messages) I think this could be implemented relatively easily as an optional feature of the mqtt-plugin.

The basic idea is to add header fields url-encoded in an additional channel level - but please take a look at the referenced documentation. It's explained much better there.

Types of Changes

[ ] Bugfix (non-breaking change which fixes issue #NNNN)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation (correction or otherwise)
[ ] Cosmetics (whitespace, appearance)

Checklist

[x] I have read the CONTRIBUTING.md document
[ ] I have signed the CA (see https://cla.pivotal.io/sign/rabbitmq)
[x] All tests pass locally with my changes
[x] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged and published in related repositories

Further Comments

However, I wonder whether the effort is worth it or whether a the pull request would have a chance to be integrated. Nonetheless I want to give it a try ;-)

I am torn in myself and can not promise yet that I will find time and muse to build a mature solution.

The pros and cons from adding this feature my point of view:

Pros:

Easy extension for MQTT clients (just publish the property bag - and use wildcard subscription to cover the properties if incoming messages)
MQTT 3.1.1 (clients) will last for a long time
Simple and powerful solution that would enhance the routing capabilities of MQTT messages in the broker

Cons:

MQTT 5 contains the feature
I am an Erlang newcomer - so few code reviews and help may be necessary
So far everything has worked without the feature

Thank you for your assessment.

pivotal-issuemaster commented 4 years ago

@alaendle Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

michaelklishin commented 4 years ago

This has slipped under our radar. @alaendle thank you! Is this a Proof-of-Concept or you have a specific action plan for finishing this before we should QA?

alaendle commented 4 years ago

Well I guess this is more a PoC than a mature solution - and I have indeed no plan for polishing the current patch. My plan was to proof that this could be implemented relatively easy and to start the discussion if this is considered to be useful and has a chance to be integrated. If this is not the case, any further work would be wasted anyway!

And to be realistic; in any case, it would be difficult (or even impossible?) for me as an erlang beginner to complete the solution to a level that can be considered production-ready. But don't get me wrong, I'm really interested to further contribute to this feature - but this would for sure need some guidance and work from experienced erlang developers.

(@michaelklishin)

michaelklishin commented 4 years ago

Fair enough. We appreciate the example we can use as a starting point in the future. Thank you!

rabbitmq / rabbitmq-mqtt