The J13 process is actually dead since quite some time. Only **work** from Lisp users and vendors from can revive it. But there is practically no work currently done. And it would be *lots* of work.

I also think that the J13 ANSI process is the wrong way. It is slow, costly, ... It is not useful in the Internet age anymore.

More movement is for example in the Java Community Standards process or in SRFI (Scheme Request for Implementation, http://srfi.schemers.org/). The SRFI looks like a good thing to me.

Well, maybe the International Lisp Conference creates some new initiatives...

Well, we shouldn't underevaluate the formidability of getting a "community standard" running. It is relatively easy to come up with one, but forcing vendors and users to follow it is a different story.

Java Community process is largely dirven by Sun's authority and money, and SRFI for great part of it by abyss of scheme users/implementors :)

And in any case, some activity in J13 at least would not harm CL.

My experience with sockets has been that no other language standardises a seriously useful socket API anyway, and for basically good reason: the underlying socket API provided by the OS is not exactly all that standard either. What does your computer do with the second argument to listen(2)? What happens to urgent data? What about SO_RCVLOWAT (is it supported?) or SO_SNDBUG (iirc, often doubled internally)?

What proportion of J13 members have read enough W Richard Stevens to do a really good job of creating a socket interface? Do we really need a half-assed one? What's (pathname-type #p"/home/dan/.emacs.gz")?

That can't be quite right; every machine implementing Java has to support the Java socket API. Now, if you're arguing that the Java API is too most-common-denominator to be useful, that's different, but it's good enough for government work...

I'd love to see the Common Lisp community take a stand as a whole and make some changes, but I'm feeling pessimistic right now, and can't see it happening.

(Anyone going to the conference at the end of the month should feel free to report otherwise!)

The java socket API is a pretty good example, yes. The java.net.Socket class has a setSoTimeout method which is described as "Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a non-zero timeout, a read() call on the InputStream associated with this Socket will block for only this amount of time"

According to the manpages on this Linux box, (a) that SO_TIMEOUT option doesn't exist anyway, (b) SO_RCVTIMEO and SO_SNDTIMEO - the obvious substitutes - are fixed to protocol-specific settings and if you want your own timeouts you have to roll them yourself using alarm() or something. So, what does calling this method on a Linux-based JVM actually do? (a) nothing, or (b) expose your application to SIGALRM signals that you weren't expecting to get (and may have installed a handler for for some other purpose)

I suspect that more poking about below the surface of the BSD sockets API will quite rapidly lead to the conclusion that about all you can meaningfully standardise is "open an active socket", "open a passive socket", and "given a socket, get me a stream". Which, sure, would be nice, but otoh currently only takes about an hour with the implementation manual to figure out anyway. There are, I think, more pressing issues (MOP support or an extensible streams protocol would be my personal favourites) for J13 or any community standards group to work on