make library no_std

[dscso]

Hi I have found the mqtt-format library and it looks promising for developing an ESP32 MQTT broker. I have already got it running using MQTTv5 on the ESP32 by adjusting the Cargo.toml. Unfortunately two things:

1. the library is not completely no_std since some features like mqttv3 are using std features. I've got it running but only with the MQTTv5 feature.
2. I have noticed, that the implementations of MQTTv3 and MQTTv5 are very different in structure, Why?

What are your intentions with this? Since I need a working implementation of serialization and deserialization would you recommend me using this code? I am willing to get it running completely on no_std without allocator, but I'd like to know your plans on this library.

Alternatively do you know another library that could suite this purpose?

[TheNeikos]

Heya! You did hit a few snags as the mqtt-format crate is currently being adapted to a newer layout.

The v3 module is using the previous layout and will be rewritten in the future.

I consider the MQTTv5 serialization/deserialization feature-complete, but there might still be a bug as I couldn't find a good way to verify it is correct and/or complete.

TL;DR:

If you only need MQTTv5, it should suit your needs. But it is not battle-tested yet, beyond normal development usage.

If you need MQTTv3 or a mature library, then you will have to wait or use another library.

Hope that clears it up!

[dscso]

I think we have similar goals, I assume you want to build an MQTT server/client (library?) and I want to build an MQTT Broker (maybe library) for embedded.

What are the places where you still see need for improvement on the parsing side? Maybe I can help.

Regarding me, what might be useful is to have a method to check how many bytes have to be received till a packet can be deserialized or maybe some codec-like thing (I don't have a full picture of how to design the broker yet). I can't use a Tokio codec but I think having a function that predicts how much bytes have to be received might be useful that everybody can build their own codec

[dscso]

I could provide a PR for no-std of mqtt-format

[TheNeikos]

What are the places where you still see need for improvement on the parsing side? Maybe I can help.

I think the biggest help would be either:

• Rewrite v3 in the same technique as v5, aka no nom, no_std and similar macro-generation of documentation etc...
• Testing v5 in every shape possible

I assume you want to build an MQTT server/client

Yeah! That's currently happening for cloudmqtt: https://github.com/TheNeikos/cloudmqtt/tree/main/src

Regarding me, what might be useful is to have a method to check how many bytes have to be received

The MQTT Protocol gives this to you inherently. Since every MQTT Packet starts with the packet type and the length of the total packet, you would have to read up to 5 bytes before knowing the total length of a packet.

Due to this, I did not see a good reason why having partial parsing would be a good idea.