Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Items for Paho Roadmap
Hi Paul,

bugs in Eclipse projects are used for all sorts of things: requests, ideas, features, design discussions we want to find easily afterwards, and yes, actual bugs.  So you should never feel hesitant to open a bug..  We always have the option of responding with "we don't want to change that", but that doesn't happen very often.

Whether the items you mention aggravate me or not should not be the question.  They are valid points for discussion, and I'd appreciate it if you put them in a bug.  I put a certain amount of error checking code into MQTTSNPacket, but I consciously didn't add everything I could have (I seem to remember) because of wanting to keep the code small-ish.  One option I have considered is putting the error checking code into conditional compilation sections, so that they can be omitted if desired.

Even though there are other MQTT-SN to MQTT gateways out there, I want to create one or more based on MQTTSNPacket/MQTTPacket so that we have a family of related tools.  Because they are related, at the source level too, hopefully it will be easier to understand them.

Ian


On 11/09/2015 04:47 PM, Paul Kierstead wrote:


On Mon, 9 Nov 2015 at 07:23 Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Maybe you could open a bug, if you haven't already, describing the oddball things?

Not knowing the culture here, I'm always hesitant to open bugs for things which are not quite bugs, but are more related to defensive programming and robustness. Here is an example:

MQTTSNString allows a pointer+len or a null-terminated style cstring. It does not have a constructor which sets the values. However, if the user does not set all values, thinking one takes precedence over the other, they will get conflicting results. For example, writeMQTTSNString(...) will favour the lenstring style; if that field is set, it will ignore the value of the cstring. However, MQTTSNstrlen(...) favours cstring; if that field is set, it will ignore the lenstring style. So if only one of the fields is initialized, you'll get varied results because different functions favour different fields. This is not exactly a bug -- the calling code should have initialized both -- but it makes debugging difficult, especially since there is no ctor.

There are some more style issues; it would be nice if pointers which are only read from were const. 

Those are the ones off the top of my head.... I should probably take notes. If those are the sorts of things you would rather have bugs logged for, I'm happy to do so. If those are the sorts of things which just aggravate you, I don't want to to that :)
 

Have you looked at this gateway? https://github.com/ty4tw/MQTT-SN



I did, and tried it out. My client, not surprisingly, was sending lots of garbage to it, and it seemed to get in a 'stupid' state fairly easily under those conditions. I looked at the code it it appeared it would take some time to figure out, and in the interests of learning the protocol I wrote a python gateway. Well, am writing, it works on a very basic level and is easy to plug lots of debugging into to see where my client is insane. It should also, hopefully, scale reasonably well. Once it has Publish and subscribe at dos 1, I'll probably call it enough for the moment; currently it handles publish, and will do the subscribe, but not the publish back to the client yet, which isn't too hard, especially for non-wild card subscribes (where you don't need to register topics to the client). Once I get it all working well and feel very comfortable with the client, I may well revisit the above gateway, though my target platform for the gateway is plenty powerful enough to run the python one (pi or BBB)

PK


_______________________________________________
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