Feature request: More comprehensive subscription management

[jonesmz]

Brief description of features:

1. Ability to call async_client::async_subscribe() before async_client::async_connect().
2. Ability for mqtt_cpp to automatically register Subscription Identifier numbers with the broker, and manage the use of them without the end-user of mqtt_cpp needing to do anything other than call async_client::use_subscription_ids();
3. Ability to register topic patterns with handler functions to be called, to offer a more convenient API than set_v5_publish_handler().

More details:

1. We already support the ability to call async_publish() before async_connect() is called. Also supporting queueing a bunch of subscriptions prior to connecting matches user expectations. We support setting the will before connecting (because the standard requires this), we support publishing messages ahead of time as well. I think we can simply support queueing all message types before calling connect(), using the same queue that we use for stored publish messages. This will prevent surprises for end users, and also make mqtt_cpp easier to use in general.

2. Subscription identifiers can save on network bandwidth, but they're complex to manage properly, especially since it's important to check before using them if the broker claims to support them. This is a feature that a lot of users of mqtt_cpp will want to take advantage of if we offered it.

3. I have three mqtt_cpp applications, each of the three of them essentially does the same behavior, where I have a list of topics I'm planning to subscribe to, and each topic has a single handler.

Right now, I have to manage a map topics <-> handlers in my own code, with a callback for conack that loops through the map and subscribes to the topics, with another callback in the publish handler that loops through the subscriptions and calls the appropriate callback.

I'd much rather have a single implementation of this, where I can provide a topic pattern, and callback, to mqtt_cpp, and mqtt_cpp manages the subscription for me, and directs any messages that match the subscription to my handler automatically.

[redboltz]

I think that 2 and 3 are implemented as a wrapper of existing APIs. If they are, nice to have.

1 is a little complicated. offline publish implementation is not a simple queue. It's a part of re-sending mechanism. Even if the offline publish message is published, the message in the queue is not erased. If message is QoS1, the message is erased when puback is received. In QoS2 more complicated message and packet_id management process is executed. QoS0 message can't publish offline.

Offline publish is not designed to general offline message sending mechanism. It is a kind of side effect like expansion of publish message re-sending mechanism.

If the benefit is just we can call subscribe() API from outside of connack callback, I think that developing effort is too much. In addition, if we call subscribe() from connack callback, we can achieve 2 and 3 independently.

[jonesmz]

The conversation about a higher level publish api fits well with this feature request: https://github.com/redboltz/mqtt_cpp/issues/420

[redboltz]

@jonesmz , yes we can implement the higher level APIs that wraps endpoint (or client).