On Tue, 2017-06-20 at 14:22 +0200, Tomasz Bursztyka wrote:
Looks like to me that net_app proposal is not growing the native
There has been discussion and complaints that the currentThanks for posting this RFC. It touches some issue I also wanted to
API that applications can use is too low level and requires lot
effort from application developer to create a bug free
Many networking operations that various applications do, are very
similar and can be provided by a library. In order to address
issues I created a higher level API that applications can use.
post RFC about: with (1st stage of) BSD Sockets work nearing
https://github.com/zephyrproject-rtos/zephyr/pull/498 , it would be
nice if all think about "responsibilities division" between 2 APIs.
The initial idea would be:
1. Native Zephyr API has the smallest code size and minimal
2. Sockets API is familiar to large audience.
Perhaps, thinking about it in these terms would help to design and
develop APIs further. For example, Sockets API is by definition
takes more code size than native API as it's implemented on top of
But if native API keeps growing, that undermines one of it
Likewise, native API is more memory efficient as it minimizes
But it also cumbersome to use. But if we try to work that around by
another API layer, still adhoc, then perhaps just using Sockets API
a viable alternative for such usecases?
It's fully optional.
Indeed, the net_app is just a bunch of helpers that make creating
networking applications a bit easier. This is not replacing any
existing api (expect the semi private net_sample API). The most helpful
thing that net_app API could bring is the transparent support for TLS
and DTLS. I have already implemented server support using TLS, and
finalizing client support.
Socket API and net_app are quite distinct. In fact, many application
oriented API are
made on top of socket API (like in python for instance).
It's just that, imo, net_app brings some low level bits from
that could be avoided.
Afaik net_app will not affect socket api layer at all.
However, as I commented on the rfc PR, net_context could gain of
which in turn would affect socket API (and bring the possibility to
It might be quite tricky to change net_context in this respect, but
lets see how it works out.