[usocket-devel] Re: usocket Scieneer support for server-side sockets

[Erik Huelsmann]

On 1/18/07, Douglas Crosher <dtc at 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.