Re: async-mqtt5 review

From: Ivica Siladic (ivica.siladic_at_[hidden])
Date: 2024-10-23 19:27:55

Hi Christian,

thanks for your review!

> On 22.10.2024., at 18:51, Christian Mazakas via Boost <boost_at_[hidden]> wrote:
> 
> 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
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Ivica Siladic