async-mqtt5 review

From: Christian Mazakas (christian.mazakas_at_[hidden])
Date: 2024-10-22 16:51:50

I'm going to vote that we REJECT async-mqtt5 from Boost.

My primary reasoning is that so far almost all the review discussion I've
seen is focusing solely on the Asio aspect which makes this a miss.

I like Asio, and I've used it to deliver products as well. But I don't
think this is the MQTT library for Boost.

I think libraries like these are a mistake because they're so heavily
focused on the ceremony of Asio that the actual meat and potatoes of the
library is lost, which in this case is supposed to be MQTT parsing and
serialization and broker management.

I think there's a lot of utility in MQTT, but what I'd like to see in the
future for libraries like these is a first-class interface _without_ I/O.
For example, I'm not sure I saw any fuzzing of the underlying parsing code.
A non-I/O based interface makes this trivial.

I also have a lot of concerns here because the library uses Asio in its
interfaces and it also internally uses Spirit. I haven't tried to compile
anything but I can only imagine the binary size and the compilation times
for a realistic project using this code.

I don't have a lot of experience with MQTT as a protocol but my operating
assumption is that if TLS/SSL can be made without I/O, so can anything
else. I think exploring this design space will lead to a much better
outcome for a library going into Boost. You can see prior art here via
rustls, OpenSSL's BIO pairs, and Botan which uses a synchronous
callback-based interface for handling things.

By focusing on creating a pure protocol library, you give users the ability
to add MQTT to their own I/O layers which has the extensibility and
genericity I'd expect from a Boost library. It will also likely enable the
library to be compiled which in this case would be a huge boon.

For example, I have an asynchronous runtime which is dramatically faster
than Asio and I'm capable of handling low-level networking coding but I
can't use this library with my own. Instead, I'd have to roll my own MQTT
support. In the ideal case, I'd be able to treat this library like I would
Botan and I'd add MQTT support non-intrusively.

All this being said, a protocol library that comes with an Asio-based impl
is perfectly fine. My only qualm is when the library _only_ supports Asio
as seems to be the case here.

- Christian