Re: [boost] Proposal for yet another MQTT library for Boost

Hi Klemens, Joaquin I just added a high level MQTT client APIs layer based on the existing packet based endpoint. The document is updated. See https://redboltz.github.io/async_mqtt/doc/latest/index.html The new high level client is https://redboltz.github.io/async_mqtt/doc/latest/tutorial/client.html It has start(), subscribe(), unsubscribe(), publish(), recv(), disconnect() APIs. And the CompletionHandler is called when the corresponding packet is received from the broker, not when packet sending is completed. So users can choose client or endpoint. For casual usecases, client can be used. For detailed operation, endpoint can be used. A code example for users is https://github.com/redboltz/async_mqtt/blob/main/example/cl_cpp20coro_mqtt.c... Implementation code is https://github.com/redboltz/async_mqtt/blob/main/include/async_mqtt/client.h... You can see the actual behavior as follows: ``` git clone https://github.com/redboltz/async_mqtt.git cd async_mqtt mkdir build cd build cmake -DASYNC_MQTT_BUILD_EXAMPLES=ON .. make cl_cpp20coro_mqtt example/cl_cpp20coro_mqtt async-mqtt.redboltz.net 1883 ``` Regards, Takatoshi Kondo 2024年4月30日(火) 12:31 Takatoshi Kondo :

Hi Klemens, Joaquin Thanks you for the feedbacks:

https://github.com/redboltz/async_mqtt/blob/main/example/ep_cpp20coro_mqtt_c... This is the code that demonstrates simple MQTT client using async_mqtt with C++20 corutine.

Underlying parts (name resolution, TCP, TLS, WS handshaking) are intentionally exclude from async_mqtt. Because users might want to customize the layers. It is similar as Boost.Beast design https://github.com/boostorg/beast/blob/develop/example/websocket/client/coro...

I think that sending MQTT packet is simple too.

However, I think that it is not a big difference.

The biggest difference between async-mqtt5 and async_mqtt is the meaning of CompletionHandler. I guess that Klemens pointed is that. Am I understanding correctly?

async_mqtt send() function's CompletionHandler is invoked when the underlying async_write is completed. async-mqtt5 sending functions (async_subscribe, async_unsubscribe, and async_publish) CompletionHandler is invoked the corresponding acknolege MQTT packet (SUBACK, UNSUBACK, PUBACK, PUBCOMP) is received.

async_mqtt recv() function's CompletionHandler is invoked when any MQTT packet is receied, in addition when connection error is happened. async-mqtt5 async_receive() function's CompletionHandler is invoked when MQTT PUBLISH packet is received.

As Klemens pointed out, async-mqtt5 easier to use than async_mqtt for casual usecases thanks to its higher level APIs. I guess that the high level APIs can be implemented on async_mqtt's comparatively low level APIs.I will consider what is the good abstraction for higher level APIs, based on your feedback.

Thanks, Takatoshi Kondo

2024年4月30日(火) 2:12 Joaquín M López Muñoz via Boost :

...

...

No dia 29 de abr. de 2024, às 17:42, Takatoshi Kondo via Boost escreveu:

Dear Boost Developers,

I'd like to propose a MQTT library to the Boost Libraries.

I’m endorsing the lib, but more generally I’m endorsing the presence in Boost of an MQTT client/server facility, which connects to the point raised by Klemens on having a conversation on the merits/synergies of the two current proposals.

Joaquín M López Muñoz

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost