[lwip-users] Regarding netconn interface

[Michael Steinberg]

Hi guys,

for my private work with lwip I ended up using NO_SYS=1 and rolling my 
own thread and api based upon the low level interfaces. But now I'm in a 
situation where I have to use the tcpip thread and am left with either 
the socket api or the netconn api. In my personal opinion, the bsd 
socket api does not really blend well into the embedded environment, at 
least if you're running the system on OS's where not everything is 
considered a file. I'm constantly in a situation where I can't 
synchronize accesses to the socket, since the select call only knows the 
lwip part of the world. So my natural course of action is to using the 
netconn api, which gives the opportunity to do manual synchronization 
with other parts of the target software and flexible sleeping due to the 
callbacks it provides.

But on the other hand I read about people's opinions that netconn should 
be deprecated or rather be considered an implementation detail, which I 
cannot really understand due to the reasons given above. My question is, 
will the api stay stable, or at least stay "there", even if it evolves? 
I have the feeling that I might spend my time using a sinking ship. Also 
I want to express my vote to "please keep an event based/callback based 
api" with this.

Regards,
Michael