Direction against fragmentation

[michalfita]

I like you project as it's focused purely on building the foundation for using the MQTT protocol in other project. What I see however is that there is already a fragmentation in the offering for Rust. Would be nice if some cooperation between these takes place - I know people quite often have different drivers to create their code, but I think it's better to have one solid implementation, that a few partially complete.

From technical point of view the observation I made in bschwind/mqtt-broker is that they used Framed<> to encode/decode their frames, what's interesting pattern. I wonder if you'd wish to add support for that as a feature. That would open the door for them and rumqtt to use the common payload definition crate in the future. Most new software is going to be asynchronous, so such addition definitely wouldn't be the waste.

I'm posting this as a discussion not a issue, because it's not feature request and idea to consider and talk through.

[00imvj00]

@michalfita thank you for sharing your thoughts and ideas. definitely, there are plans to upgrade library to provide standard support for sync as well as async. Once the experiments are done, I will be adding partial features which make this library capable of handling sync, async with different executors also.

[michalfita]

Thanks for the response. I think you've done great job here and it would be really nice if other MQTT projects can use one proven payload foundation.

[00imvj00]

that is the idea, @michalfita :)