Example of a reconnect client

[kleunen]

No description provided.

[codecov]

Codecov Report

Merging #785 (fda94f9) into master (cc8927a) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #785   +/-   ##
=======================================
  Coverage   85.03%   85.03%           
=======================================
  Files          64       64           
  Lines        8932     8932           
=======================================
  Hits         7595     7595           
  Misses       1337     1337           

[kleunen]

With wandbox.org, would it be possible to import a library.
For example. it would be nice if you could "import" the mqtt_cpp repository and compile and run the example on wandbox.org.

[kleunen]

I do not fully agree with your comment every example should only show one aspect, please consider my thoughs here:

I think the reason users are using this library is to setup a client connection with an mqtt broker. There are now many examples: no encryption, tls, ws, sync/async and server. I would say the user is more helped with a single example showing a pattern how to use the library to setup a MQTT client connection. I think actually one example would suffice, if this would show how to setup a connection, subscribe, reconnect and publish, this would be sufficient. And this example could do all possible connection: tls/raw TCP, ws.

I also do not understand why two approaches to the client: sync and async. Like you said, the mqtt protocol requires the callbacks because of the nature of the protocol. The sync/async is only for the connecting, correct ?
But why support both, it is only a minor difference?

I hope you consider this feedback, i am just thinking out loud what would be a good example of the library.

[redboltz]

With wandbox.org, would it be possible to import a library.
For example. it would be nice if you could "import" the mqtt_cpp repository and compile and run the example on wandbox.org.

You can write a PR to https://github.com/melpon/wandbox-builder.

For example, boost(experimental) sml is added as follows:
https://github.com/melpon/wandbox-builder/blob/8e7231cacd6016c478a28cb0ed67a236d04ec86e/build-head.sh#L158

I think that not only here but also other setting might be required to adding a new library.

[redboltz]

I do not fully agree with your comment every example should only show one aspect, please consider my thoughs here:

I think the reason users are using this library is to setup a client connection with an mqtt broker. There are now many examples: no encryption, tls, ws, sync/async and server. I would say the user is more helped with a single example showing a pattern how to use the library to setup a MQTT client connection. I think actually one example would suffice, if this would show how to setup a connection, subscribe, reconnect and publish, this would be sufficient. And this example could do all possible connection: tls/raw TCP, ws.

I don't have a plan to remove examples. It is documented on the README.md.
When I try to use the MQTT client library such as MQTT.js, paho, HiveMQ, mosquitto, etc, the combination of TLS, WebSocket, and TCP support is very important. For example, paho with wss is very hard way for me.
Typical user needs to refer to no_tls_client.cpp. So I place it on the top of example.

I also do not understand why two approaches to the client: sync and async. Like you said, the mqtt protocol requires the callbacks because of the nature of the protocol. The sync/async is only for the connecting, correct ?

No. All sending API has sync version and async version.

But why support both, it is only a minor difference?

I'm an advanced user. I use async sending APIs for performance critical case. e.g. my proprietary broker.
But it is difficult to use. User needs to manage all lifetime expect some exceptions.
For example, payload, topic_name, topic_filter, and so on.
If user use async sending APIs, the user also needs to care the handler return point.
If async send API is called and returned and returned from the receive handler, then the next read started immediately.
The async send API might not write the message to the socket.
There is a mechanism to delay the next read.
Anyway, it is for advanced users.

On the contrary, sync sending API is very simple. User doesn't need to care the lifetime except QoS1 and 2 publish.
It is easy to understand and straight forward. But performance is less than async APIs.

Anyway, I will merge the PR.