[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [paho-dev] Contributing and coding standards?
|
Daniel, Greg,
the embedded client is structured as a toolkit. The core code,
MQTTPacket, MQTTClient.h (C++), is the very portable section, so needs
to be written in as platform agnostic a way as possible.
The platform specific 'plugin' code that creates the interfaces between
the core and the OS, can be written in as platform-specific a way as you
or I like.
Ian
On 03/12/2018 22:27, Daniel Santos wrote:
Hello Greg,
I've had to spend time on another issue (and being sick) so I won't be
able to get back to this until it's fixed, hopefully just a few more weeks.
On 11/15/18 6:34 PM, Greg Troxel wrote:
I definitely am in favor of writing to the POSIX spec instead of linux
man pages. That gets you portability to a huge range of systems,
including ones you don't even know exist.
Usually, libraries are written to POSIX, perhaps relying on as little as
necessary. But, there are platforms which are much less than POSIX,
like the Arduino IDE. I am not quite clear on if your platform is not
posix (an unhosted environment like one might have with the Arduino
IDE?) or if you are just wanting things to be leaner. It seems to me
that lean, and a non-POSIX environment are two separate issues, and that
lean would benefit almost everyone, especially if the issue is CPU and
memory use vs code size.
About socket and timer: when designing for arbitrary less-than-POSIX
environments where you try to assume C99 (or C++NN) and no further, you
run into needing various things that aren't in that spec, and then
defining interfaces that the platform has to define to use the library.
I think that's what you mean about Socket and Timer.
Yes, and I'm basing this off of the current support for GNU/Linux,
Arduino and mbed that are under MQTTClient/src/mqtt.
I would suggest, without certainty, that if you need something that
exists in POSIX (like sockets), that you consider using that or a
defined subset, and then ask the platform to define the calls that POSIX
expects. This reduces brain effort for readers, as they know the
interface, and you will probably find that many systems that are C99 but
not POSIX do various things that are posixy the posix way.
Well this isn't my idea, but I like it! I'll need to analyze this more
carefully to make sure that it makes sense however. In some cases this
could add some overhead as an interface may be designed to do many
different things (with lots of different structs that are initialized,
etc.), but if that isn't too cumbersome then it may be the way to go.
Also, it may be good to have the platform API in C, not C++ - but that
may be my old-school bias showing.
Hope this helps...
This will allow us to abstract away the language-level interface
somewhat with very little potential overhead.
Ian, what are your thoughts? I can probably start on something in a few
weeks. I also want to keep the design such that it can all end up in a
single translation unit (excluding the MQTTPacket layer).
Thanks,
Daniel
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Eclipse Paho Project Lead & Mosquitto Committer
