Re: [lwip-devel] brain storming about "socket2"

[Micael (abc)]

Den To, 2009-01-15, 14:08 skrev Jonathan Larmour:
>>> * Coming back to why I am concerned about sockets in lwip: I fully
>>> realize that an open source project is what everyone contributes to
>>> it, but I get the feeling that most of you active developers are not
>>> using the socket API,
>>
>> That's not true. That's not even true of me - I have existing code around.
>> As Simon says, the socket API is working and supported. You only have to
>> look at the effort spent on improving it in the 1.3.0 release to see that.

OK, then I misunderstood you. Sorry for that. It is good to hear that
there's a commitment with sockets.

>>
>>> and too me, it is not clear where you guys as a
>>> community wants to take lwip/sockets. I also see piero struggling with
>>> different issues that from where I stand, looks like real flaws.
>>
>> I don't think Piero has been reporting flaws? Rather, wanting
>> enhancements.

Probably my misunderstanding, then. I was reading about the memmp issues
needing a stack restart. However, that is a different thread, and probably
no relevant to this discussion!

>> lwIP is lightweight, and being lightweight has not always
>> had every feature. So yes, not every socket operation can be used
>> non-blocking yet.

Yes, this is totally clear to me!

>> But as you've maybe seen from the "Success stories"

Yes, I have seen them, which is great, but afaict, the might well be
netconn implementations.

>> thread, and the number of people on this list, that's not a big problem
>> for most people. (Although that support probably will be added in the
>> not-too-distant future probably).

OK, You have won me back ;-)  Like I said, I really like lwip as such, and
the unix simul environment is a great help.


Since I kind of drove this subject/thread off road, I better try to pull
it back again.. ;-)

So, as far as I can tell, we have two roads from here, where some of us
prefers better socket compliance to POSIX, and others prefer higher
efficiency, by accepting deviations from the standard.
Both targetting socketX to work with the raw API directly.



Regards,
 Micael