|Re: [paho-dev] Embedded MQTT C Client|
Hi Sergio,I always intended that the various levels of embedded API would be exposed and used, because in general, the easier they are to use, the more resources they take. Ideally these APIs will cater for any application. (http://modelbasedtesting.co.uk/?p=94).
I did not intend originally that there would be an MQTTClient layer in C, only C++. But our experiences with a couple of platforms showed that C++ support in some cases is not ideal, where C is the de facto standard. So the MQTTClient-C package is intended as a "copy" of the embedded MQTTClient package, a higher level API for C environments. The C++ and C versions of these APIs could and should be identical, except for the replacement of C++ classes with C structures. This would simplify the maintenance of the two APIs. (I have toyed with the idea of generating the C code from the C++ code, with a script.)
It had occurred to me to use the MQTTPacket_read() function in MQTTClient(), but it didn't quite fit, which resulted in an almost duplicated function (readPacket() in C and MQTT::Client::readPacket() in C++). If they could be rationalized into one, that might be a good thing.
By the way, we're intending to produce similar higher level embedded clients for MQTT-SN - so similar considerations apply there too.
So, yes, MQTTPacket is intended to be used in its own right where the lowest resource use is needed. Making it as helpful as we can is great. I view MQTTPacket as a toolkit, from which you can take the pieces you need, whereas MQTTClient and MQTTClient-C are more holistic APIs.
If you shared your proposed APIs here maybe that would help the discussion? Ian On 09/23/2014 02:07 AM, Sergio R. Caprile wrote:
Hi guys, just git pulled and bumped into a new MQTTClient-C directory in the tree and after reading some messages in the list I think we are doing the same from different sides. Last month I removed the transport specific parts from the MQTT-SN library and provided clean samples. Last week, I Just started doing the same on MQTT, so I basically developed a set of low-level routines accessed by MQTTPacket. After having problems on low-speed links I realized the packet reader was not following the usual behaviour with TCP, so I checked with Ian and started modifying MQTTPacket.c. Now that I see the client code and read some msgs, I guess you guys are probably doing the same... we should coordinate on a "transport" interface that both use, or the client delegate on the packet, or the packet on the client, but just one of these... do you guys agree ? I vote for the transport API for two reasons: 1) It's almost done(*) 2) Presents a similar interface as the one in MQTT-SN library 3) Someone might not need a full client and could get along with just the MQTTPacket code 4) Both, Client and Packet, remain independent. Please correct me if I'm wrong. (*) So far I have a simple transport API, OS-agnostic, with non-blocking functions, that, even though it needs extensive debugging, seems to be working (with small test messages) Regards _______________________________________________ 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 Committer on Paho, Mosquitto
Back to the top