Re: Proposal for yet another MQTT library for Boost

From: Takatoshi Kondo (redboltz_at_[hidden])
Date: 2024-05-01 06:35:04

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.cpp

Implementation code is
https://github.com/redboltz/async_mqtt/blob/main/include/async_mqtt/client.hpp

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 <redboltz_at_[hidden]>:
>
> Hi Klemens, Joaquin
> Thanks you for the feedbacks:
>
> https://github.com/redboltz/async_mqtt/blob/main/example/ep_cpp20coro_mqtt_client.cpp
> 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/websocket_client_coro.cpp
>
> 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 <boost_at_[hidden]>:
> >
> >
> > > No dia 29 de abr. de 2024, Ã s 17:42, Takatoshi Kondo via Boost <boost_at_[hidden]> 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