[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
