Re: Proposal for yet another MQTT library for Boost

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2024-04-29 16:51:43

I have looked over your documentation, and I think I'd prefer mireo's
API for clients. Your library seems more low-level, which is not ideal
for simple clients.

However, support for a server is a different story. I think there
might be space for two libraries, mireo/async-mqtt5 as the easy-to-use
client, and your library as the low-level one for fine-tuning and
servers.

I would be very interested how you and the mireo team see any
potential overlap/synergy/conflict with those two mqtt libraries.

On Mon, Apr 29, 2024 at 11:42 PM Takatoshi Kondo via Boost
<boost_at_[hidden]> wrote:
>
> Dear Boost Developers,
>
> I'd like to propose a MQTT library to the Boost Libraries.
>
> Repository link: https://github.com/redboltz/async_mqtt
> Document link: https://redboltz.github.io/async_mqtt/doc/5.0.0/index.html
>
> Here is characteristics of async_mqtt:
> - C++17 or later is required.
> - async_mqtt supports Boost.Asio style completion tokens.
>   - e.g. use_future, deferred, use_awaitable, callback functions, etc
> - Not only MQTT client but also MQTT server is supported.
>   - User can use this library to develop MQTT broker.
>   - Sample MQTT broker application is included.
> - Both MQTT v3.1.1 and v5.0 are supported.
>   - In addition, undetermined protocol version is supported for server
> implementation. In this case, the protocol version is decided when you
> receive CONNECT packet.
> - Continuous packet sending
>   - Users can send the next MQTT packets before the previous sending
> is not completed (completion handler is not invoked yet).
> - Auto acquiring/mapping topic alias is supported.
>   - In addition, when resending a PUBLISH packet after reconnecting,
> the topic alias is removed and the original topic is restored. It is
> required by MQTT v5.0 spec.
> - Packet based send()/recv() APIs.
>   - MQTT has various packets and some of their fields are optional. In
> order to keep simple APIs, async_mqtt uses packet based APIs.
>   - See https://redboltz.github.io/async_mqtt/doc/5.0.0/tutorial/send_recv.html
> - Layered archtecture
>   -  async_mqtt can have predefined TCP, TLS, WS, WSS, and user
> defined underlying layer. Users can access the underlying layer using
> next_layer() member function of MQTT endpoint. So you can configure
> any layers by yourself. e.g. tcp_no_delay, set send/recv buffer size,
> etc
>   - See https://redboltz.github.io/async_mqtt/doc/5.0.0/tutorial/create_endpoint.html
> - High performance
>   - See https://redboltz.github.io/async_mqtt/doc/5.0.0/performance.html
>
> Background
>
> I have developed another mqtt library mqtt_cpp
> https://github.com/redboltz/mqtt_cpp since 2015. It is widely used but
> has some limitations. For example:
> - The functions are directly mapped to packets(publish, subscribe,
> etc), so optional features are not designed cleanly.
> - Due to set_publish_hander / on_publish style handler design,
> Completion Token cannot be supported.
>
> Based on this 9years experience, I designed the new MQTT library. This
> is async_mqtt.
>
> I would appreciate if you could endorse this library.
>
> Regards,
> Takatoshi Kondo
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost