[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [paho-dev] Building the C++ API/samples
|
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