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