On 1/18/07, Douglas Crosher dtc@scieneer.com wrote:
Erik Huelsmann wrote:
Hi Douglas,
I committed server side socket support to all backends but SCL. From what I saw from the parallel between CMU and SCL, I probably could code most of the required change, but, since I can't test it anyway, I'm asking you to have a look at the 3 new functions to get the SCL backend up to par.
- SOCKET-LISTEN (host port &key reuseaddress backlog)
- SOCKET-ACCEPT (socket)
- SOCKET-CLOSE ((socket stream-server-usocket)) (method)
I'll be putting :element-type support into place in the SOCKET-LISTEN function as an additional key argument. For now, that's what usocket will be supporting, seeing if all this energy pays of and people actually start using usocket (instead of recommending it to others in IRC :-)
Thank you. A patch is attached adding support for the Scieneer CL.
No! Thank you! You have by far been the most cooperative Lisp vendor! (Though LispWorks' Xanalys was helpfull too.)
The patch didn't apply cleanly, so, I copy-pasted it into the file. I've committed the change in r177 ; could you verify correctness please?
Would the project consider changing the definition of a socket to be just an encapsulation of the underlying Unix file descriptor, rather than also requiring a stream to be created for each socket. This would shift the element-type and external-format issues to the stream layer.
Yes, I will consider that. I started myself to work from the other way around though: I'm working on a document which specifies a format for :external-format meaning to submit it as a CDR document (see http://cdr.eurolisp.org/).
A function could then be provided to create a stream for reading and writing from a socket, and this could deal with external-format conversion between a usocket convention and implementation conventions. Applications could then be ported to CL implementations with high performance stream layers whereas currently applications will need to use flexistreams and require rewriting to exploit the performance of each CL implementation which defeats the purpose of a portable interface.
Lacking a finished document, this could indeed be an intermediate solution. I want to get server sockets 'out on the street' as soon as possible though. This means that I'll need to implement :element-type support soon. After that 0.3.0 can be released which would be a start for the project to draw attention. I'm hoping that with the additional attention more people will be contributing to the project (be it in terms of code or by helping discuss design decisions).
Thanks once more for your contribution!
Would you be interested in receiving a copy of the draft CDR document?
bye,
Erik.