[snipped some context]

>> Yes, avoiding portability layers is a goal.. so when you state " it is
>> just a matter of creating a small layer on top of them (like
>> usocket)", we're directly against that goal. usocket and the like
>> exist already, so there's not much value in working to standardize the
>> interface... just use usocket! :)
>
> Well, maybe I didn't expressed myself clearly. And I didn't quite get your
> point. If you go down that road, we could say that we don't need to
> standardize FFI or threads as well ("just use CFFI or bordaux-threads" -
> usocket is just as much of a portability layer as CFFI or bordeaux-threads
> is). In the part of "just create a small layer on top of them", I meant
> internally in each implementation. Each implementation will take the
> functions to manipulate sockets that it already has and create the standard
> functions on top of them or make small modifications appropriately to make
> those functions conform with the standard.

Right, i getcha, and i don't necessarily disagree. But, why require
that an implementation have sockets when you don't need them to be
implementation specific?

Sure, given sockets you can create a crude FFI, but it will not be
fast or pretty. However, the socket interface i can create via FFI and
extensible streams is just as good, if not better, than those provided
by individual implementations.

What if i want more functionality for our sockets then those provided
by an implementation? do i ask the implementation to implement my
extension? Again, if we try to force implementors to do anything,
we've lost. We need to gain traction and momentum first.

The point i'm trying to make is that including sockets and networking
in the CLtL3 specification (it's not a standard, lets not call it one)
will require work, and potentially a lot of work, on both our parts
and the parts of implementors. I see a good argument for excluding
them (a perfectly good implementation can be built on the features we
provide), but i've yet to hear a good argument for providing them (in
the description rather than the library) beyond 'because some
implementations have sockets already'.

 [snipped]

Thanks for all the feedback! Your input has been quite valuable so far.