Re: [paho-dev] Building the C++ API/samples

[Frank Pagliughi <fpagliughi@xxxxxxxxxxxxxx>]

Yes, that is a good approach. I mention a few additional things inline...

On 11/15/2013 11:51 AM, Ian Craggs wrote:
> I was thinking about having a separate codebase in Paho

Yes, I was thinking a split would be good, because the constraints on a 
a really small system would be painful for someone with a more capable 
OS. Regardless of the size/power of the board, the two things I look for 
are (1) whether the OS has standard API's like Posix and BSD sockets, 
and (2) whether the chip has an MMU and supports virtual memory.

> a) some sort of pluggable lower layer so it was easy to port to 
> different networking and other system libraries

Yes. It's pretty easy to write a portable layer around the basic OS 
support for a small system that has a threaded RTOS. Most have similar 
capabilities. The one distinction that makes a big difference (though I 
may be wandering into the weeds here) is whether the OS supports 
Condition Variables. If so, they are a great building block for 
everything else. Otherwise the system requires a higher-level work-around.

As for the networking model, many libraries try to mimic the BSD socket 
interface with varying levels of success. But that should always be the 
default options. Many libraries also have a lower-level, proprietary 
API. LwIP is a perfect example. The decision would need to be made 
whether to target the upper or lower level API's for these libraries.

> b) a simple threading model, say one thread per client object, as 
> simplicity is top priority

Yes, and also remember that many little RTOS' are strictly prioritized, 
and some do not even allow two threads to be the same priority. So we 
would need to make sure that the threads can be provided individual 
priorities and support cases where they can or can not be assigned the 
same or priority.

Another decision is whether to keep/provide separate Synchronous and 
Asynchronous API's. I think that would be wise. On bare-metal systems 
without an RTOS, it may be sufficient or necessary to provide just a 
simple, synchronous interface. We should make sure that the Synchronous 
library could be compiled separately without a lot of dependencies.


> c) still using standard C, for maximum portability and small size (is 
> that still a benefit?)

Yes. I haven't seen a system in years that doesn't support standard C.

The main thing to keep in mind is that for a small system lacking an 
MMU, the bane of the programmer is dynamic memory. Using malloc will 
fragment the heap and eventually fail. So malloc should not be used 
directly, and any allocation should be done from within a pluggable 
layer that can be swapped out. The choices might be something like:
(1) Don't do any allocation in the MQTT lib. The app must supply all 
buffers. Keep copying to a minimum.
(2) Provide an allocation layer that uses malloc/free as a default 
reference implementation and let the user drop-in a required replacement 
for their system
(3) Provide a basic fixed-size block allocator which can be swapped out 
if the system has a better one.

Just some thoughts.
Frank