|Re: [paho-dev] Java client library|
Hi Dwayne,as the Java client has been released at a mature version level (1.0) we can't break the API unless we move to a new major version number (2.0), which I don't want to do right now. Overloading is fine, but moving the URI is not possible.
In MQTT 3.1, the client identifier really was compulsory. Only in 3.1.1 did sending a zero length client id become an option, and many APIs were designed before the 3.1.1 standard appeared. For APIs still under development, like the Lua one, then we can design them around the 3.1.1 features.
Also, for those APIs that have some form of persistent store (the Paho Java and C clients for example), the clientid is used as a key into that store. You can recreate a client object with the same clientid, and the previous state (inflight messages) will be restored. At least in the C client, this is done at create time; you can then inquire on that state before issuing the connect call.
Ian On 10/07/2014 01:47 PM, Bradley, Dwayne wrote:
With Roger Light's clarification on a previous thread about the Lua client, and my new knowledge that the client identifier not really being required for a MQTT client connection to a broker, I'm wondering if the constructor for the MqttClient class in the Java library should be modified. Should the MqttClient class constructor be overloaded so we could only pass the URI? Possibly move the identifier to the MqttClientOptions class since it is truly optional? Thoughts? Dwayne Bradley Technology Development Manager Emerging Technology Office Duke Energy _______________________________________________ paho-dev mailing list paho-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/paho-dev
-- Ian Craggs icraggs@xxxxxxxxxx IBM United Kingdom Paho Project Lead; Committer on Mosquitto
Back to the top