<br><br><div class="gmail_quote">2009/9/2 Drew Crampsie <span dir="ltr"><<a href="mailto:drewc@tech.coop">drewc@tech.coop</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[snipped some context]<br>
<div class="im"><br>
>> Yes, avoiding portability layers is a goal.. so when you state " it is<br>
>> just a matter of creating a small layer on top of them (like<br>
>> usocket)", we're directly against that goal. usocket and the like<br>
>> exist already, so there's not much value in working to standardize the<br>
>> interface... just use usocket! :)<br>
><br>
> Well, maybe I didn't expressed myself clearly. And I didn't quite get your<br>
> point. If you go down that road, we could say that we don't need to<br>
> standardize FFI or threads as well ("just use CFFI or bordaux-threads" -<br>
> usocket is just as much of a portability layer as CFFI or bordeaux-threads<br>
> is). In the part of "just create a small layer on top of them", I meant<br>
> internally in each implementation. Each implementation will take the<br>
> functions to manipulate sockets that it already has and create the standard<br>
> functions on top of them or make small modifications appropriately to make<br>
> those functions conform with the standard.<br>
<br>
</div>Right, i getcha, and i don't necessarily disagree. But, why require<br>
that an implementation have sockets when you don't need them to be<br>
implementation specific?<br>
<br>
Sure, given sockets you can create a crude FFI, but it will not be<br>
fast or pretty. However, the socket interface i can create via FFI and<br>
extensible streams is just as good, if not better, than those provided<br>
by individual implementations.<br>
<br>
What if i want more functionality for our sockets then those provided<br>
by an implementation? do i ask the implementation to implement my<br>
extension? Again, if we try to force implementors to do anything,<br>
we've lost. We need to gain traction and momentum first.<br>
<br>
The point i'm trying to make is that including sockets and networking<br>
in the CLtL3 specification (it's not a standard, lets not call it one)<br>
will require work, and potentially a lot of work, on both our parts<br>
and the parts of implementors. I see a good argument for excluding<br>
them (a perfectly good implementation can be built on the features we<br>
provide), but i've yet to hear a good argument for providing them (in<br>
the description rather than the library) beyond 'because some<br>
implementations have sockets already'.<br></blockquote><div><br>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.<br>
<br>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.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div></div> </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div> [snipped]</div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"></div>
<br>
Thanks for all the feedback! Your input has been quite valuable so far.<br></blockquote><div><br>You are welcome. I'm just having some fun.<br><br>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 <a href="http://common-lisp.net/project/trivial-shell/">trivial-shell</a>) a way of getting the so-called "posix-argv". The last three might fall in the "OS and Filesystem access" topic.<br>
<br>Cheers,<br>Gustavo.<br></div></div><br>