Description
This issue concerns the refactoring
branch only.
After subscribing using a topic filter and a callback, it is possible to subscribe using the same arguments (or a different callback) again. What should happen in such a case? Following scenarios seem possible to me:
-
If the QoS of the new subscription is the same as the old one, the callback of the existing subscription is replaced. No further action is taken.
-
If the QoS of the new subscription is different from the existing subscription, we need to unsubscribe and subscribe afterwards using the new QoS. This is actually quite hard to implement in the current architecture since we could only send the first SUBSCRIBE request once we received the UNSUBACK.
-
If the QoS of the new subscription is equal or lower to the QoS of the existing subscription, we simply add the new callback to the callback list of the subscription, so that each callback is invoked when a matching message is received.
-
If the QoS of the new subscription is higher than the QoS of the existing subscription, we also would need to unsubscribe and subscribe again, but without removing the previous callback. This is actually a mix of options 2 and 3.
-
We do not allow existing subscriptions to be overwritten by throwing an exception (this has been the previous behavior).
-
One of options 1 or 3, but combined with 5 so that changing QoS is invalid.
Personally, I would prefer option 5 since it is by far the easiest solution and one would most likely not expect the library to perform complex tasks upon subscribing to the same topic again (which most likely happens by accident only anyway).
@thg2k Can you leave your opinion on this?