[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [paho-dev] Building the C++ API/samples
|
Yes. Count me in.
On 11/15/2013 08:08 PM, Ian Craggs wrote:
Hmm, my second phase of editing didn't go well there. Too many Franks.
On 16/11/13 01:06, Ian Craggs wrote:
Frank,
thanks for the comments, Frank, very helpful.
Would you like to collaborate in some way?
Ian
On 15/11/13 18:00, Frank Pagliughi wrote:
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
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev