2 octobre 2024 à 18:51 "Christian Mazakas via Boost"
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.
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.
I'm surprised that this remark did not raise more reaction. I'd like to put a very big +1 on what Christian said. For what it's worth, the platforms i'm currently mostly working with are Xenomai/Linux and FreeRTOS. Asio is unusable on both. I don't think it can be used on Zephyr OS as well. AFAIK it can't be used in any real time / embedded os (well, maybe RTLinux or Qnx). MQTT is advertised as an IOT protocol. I know so-called things are growing more and more to be standard linux devices, but there are still plenty of them which are not. My understanding is that the proposed library is not usable in such platforms, due to the lack of asio. Is that correct? If it is, the next question is what would be the amount of effort that would be needed to put the parsing / interpretation layers outside the networking layer, and if there are there any plans to do it? Christian mentionned fuzzing as an immediate benefit. My experience tells the same, pure protocol libraries are a lot easier to unit test than io libraries.
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.
I would even add that supporting asio is a very good case of testing the validity of the design of an underlying protocol library. A pure protocol library which has not been tested against asio may well miss its target. Regards, Julien