Re: [paho-dev] Contributing and coding standards?

[Daniel Santos <daniel.santos@xxxxxxxxx>]

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