Closed ghost closed 9 years ago
Hello Tommy,
Sorry for not getting back to you faster. I have never had this requirement for any of my uses of MQTT. And the client code doesn't currently maintain a local copy of subscriptions.
I don't think I fully understand your use-case and why a client would unsubscribe from a topic due to a update from another topic. But I suspect it would best be handled in your application code - with a wrapper round the subscribe/unsubscribe functions.
nick.
Hi Nick,
I think most of your use-cases just require the application codes to subscribe to mqtt broker statically, i.e. after subscribing, there is no further change. But for my use-case, I keep receiving update from an event. Thus I have to sub/unsubscribe accordingly.
You are right that I can handle it in my application code, which is what I'm doing today. But I think if there are more interests in implementing it within this gem, we can start to think about it. At the moment, this can be closed.
I'm thinking about implementing a method to get all topics that the client subscribes to. Use case is as bellow:
1) Client subscribes to topics [A,B,C,D] 2) A new update comes in. Client has to subscribe to [B,C,D] ONLY. 3) Therefore, if I can retrieve the topics that client has subscribed to before ie. [A,B,C,D], I only have to ask client to unsubscribe to [A] since I know that by [A,B,C,D] - [B,C,D] = [A]. Otherwise, I have to ask client to unsubscribe to [A,B,C,D], and then subscribe back to [B,C,D].
Any thought?