2009/9/2 Drew Crampsie drewc@tech.coop
[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'.
All right, I guess you won this discussion. I won't die for not having a per-implementation interface for sockets. I guess I did not had in mind that implementors might or might not like Cltl3 and choose to comply with it or not to care at all.
But, in any case, as I see in usocket's page, all currently alive implementations that I am aware of (except perhaps Corman CL) have at least the basics for sockets.
[snipped]
Thanks for all the feedback! Your input has been quite valuable so far.
You are welcome. I'm just having some fun.
There are still a bunch of minor things that could be be included in Cltl3, but I don't know yet how much effort this might take, so this is just a suggestion. Hooks (hooks for when the gc runs, for when Lisp initializes and finishes (useful for when you save and load images and need to do some setup or teardown) and possibly others). There are also functions like quitting lisp, running an external program, access to a shell (like trivial-shellhttp://common-lisp.net/project/trivial-shell/) a way of getting the so-called "posix-argv". The last three might fall in the "OS and Filesystem access" topic.
Cheers, Gustavo.