Since the spec allow for multiple topics in a subscribe message I would think that changing the api to allow for multiple topics would be sensible.
Don't have the code in hand, but does the return array also have QoS? Since that's the response from the broker it would make sense for the return to be topic/qos pairs. Although if it's currently only an array or topics that would be breaking. It would however be a simple fix, and I doubt many implementations actually check the return value.
This doesn't really make sense/looks a bit silly. So the question is what do we do about it? To change to only return a single value is the obvious and easiest solution to implement, but would potentially break someone who updated the client without updating their app, and being as we've just done a 1.0.0 release perhaps changing the API isn't such a good idea.
Alternatively we could allow subscribe to be passed multiple topics/qos, keep the currently returned array and just populate it as appropriate depending on the number of topics in the subscribe.
I'm looking for opinions on the above or any other options for resolving this, either here or on the bug.
paho-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top