Hi Paul,

There has been discussion and complaints that the current net_context
API that applications can use is too low level and requires lot of
effort from application developer to create a bug free application.
Many networking operations that various applications do, are very
similar and can be provided by a library. In order to address these
issues I created a higher level API that applications can use.

Thanks for posting this RFC. It touches some issue I also wanted to
post RFC about: with (1st stage of) BSD Sockets work nearing completion
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 overhead.
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 it.
But if native API keeps growing, that undermines one of it benefits.
Likewise, native API is more memory efficient as it minimizes copies.
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 is
a viable alternative for such usecases?

Looks like to me that net_app proposal is not growing the native API. It's fully optional.
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 net_context 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 some changes,
which in turn would affect socket API (and bring the possibility to emulate select())


Tomasz