Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Lua client: Changing connect method

I don't think that any particular model of API has shown itself to be better than any other up to now. Each has its merits and demerits. Some of the design decisions are affected by the features and conventions of the programming language in question, and the features of the particular API being designed.

Now, the URI of the server doesn't feature in any MQTT packet, so it could go on any method. One reason for having the URI and clientid on the constructor in the Java and C clients is, as I mentioned before, because they are used as a key for the persistence store. If persistence is a feature of the API, then the placement of these parameters can affect when you can read the store. Another reason is that it reduces the chance of mistakes when reconnecting a non-cleansession client, because we don't have to get the clientid and URI correct again.

Ian


On 10/10/2014 05:54 PM, Kevin KIN-FOO wrote:
Hi Dwayne,

My main reason about staying different from Java client is staying
close to specs.

The connect method I advocating for is closer to connect description
given by MQTT itself.
I also believe it will be easier to use this way.
When you know about MQTT specs you will know where to search in lib API.

I want it to be as bare simple as possible.

I do appreciate you being interested and wondering about what going on
with Lua client.

Kevin

On 06/10/2014 23:43, Bradley, Dwayne wrote:
I'm like Ian  when it comes to not knowing much about Lua but I have
a couple of quick observations after previously coding with the Java
client and having just recently played with the Lua client.

Is there a reason to not follow the Java model a little closer with
the Lua client?  For example, when we create new MqttClient object
using the class' contructor in Java, we pass:

- The URI to the server and,
- The client identifier.

These are the required parts of a MqttConnection.  Any reason to not
make the Lua client similar in this regard?  Currently the create()
method of the Lua client passes:

- The IP address,
- Port and
- A callback method/pointer/or whatever it is called in Lua.

Why not put the identifier in the create() method as well since it is
a required piece of information for the connection?  Any reason to
not change the IP address/Port parameters over to a single URI
field?  I do realize that we would have to handle setting the
callback method differently than in Java though.

After the client object is created, we then call the connect() method
on that client instance.  When we do this in Java, we have 2 options
because of overloading:

1) Calling connect() with no parameters (i.e. no optional parameters
required) or
2) Calling connect() with an MqttClientOptions object that contains
all of the non-required part of a connection.  I think that this is
partially what you are looking at by using a Lua table for the
parameter but I personally would like to see what could be passed in
this table being more defined (but then again, I'm not very familiar
with Lua and how things are normally structured).

These non-required options are:

- Clean session flag
- Connection timeout
- Keep-alive interval
- Username
- Password
- SSL info
- Will topic info

I kind of like having the required portions of a connection being
separated from the non-required portions and I feel like the current
Java implementation does that nicely.

Just food for thought.

Dwayne Bradley
Technology Development Manager
Emerging Technology Office
Duke Energy


-----Original Message-----
From: paho-dev-bounces@xxxxxxxxxxx
[mailto:paho-dev-bounces@xxxxxxxxxxx] On Behalf Of Ian Craggs
Sent: Monday, October 06, 2014 5:09 PM
To: paho-dev@xxxxxxxxxxx
Subject: Re: [paho-dev] Lua client: Changing connect method



*** This is an EXTERNAL email. Exercise caution. DO NOT open
attachments or click links from unknown senders or unexpected email. ***

All sounds good to me (not knowing much about Lua).

Oh - the client identifier no longer has the 23 character limit in
MQTT 3.1.1.

Ian

On 10/06/2014 04:53 PM, Kevin KIN-FOO wrote:
Hi,

I think we should change connect method to stick better whith MQTT 3.1
[1].

As I am writing this method method looks like:

   function MQTT.client:connect(                                     --
Public API
     identifier,    -- string: MQTT client identifier (maximum 23
characters)
     will_topic,    -- string: Last will and testament topic
     will_qos,      -- byte:   Last will and testament Quality Of
Service
     will_retain,   -- byte:   Last will and testament retention status
     will_message)  -- string: Last will and testament message

I think it should follow specs and include authentication parameters.
Result is:

   function MQTT.client:connect(                                     --
Public API
     identifier,    -- string: MQTT client identifier (maximum 23
characters)
     will_topic,    -- string: Last will and testament topic
     will_message,  -- string: Last will and testament message
     user_name,     -- string: User who is connecting
     password,      -- string: Password corresponding to the user who
is connecting
     will_qos,      -- byte:   Last will and testament Quality Of
Service
     will_retain)   -- byte:   Last will and testament retention status

Even better allowing to provide parameter within a table.
It avoid passing silly "nil" while connecting.
So users could type:

   client:connect({
     identifier = id,
     will_topic = will,
     will_retain = 'So long',
   })

Looking forward for comments.

Kevin

[1]
http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.ht
ml#connect _______________________________________________
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

_______________________________________________
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
_______________________________________________
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

_______________________________________________
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