[usocket-devel] [drakma-devel] [patch] Resubmit drakma timeout for sbcl.

[Nikodemus Siivola]

2011/3/28 Chun Tian (binghe) <binghe.lisp at gmail.com>:

> Well, I think maybe the two projects (USOCKET and SBCL) didn't collaborate
> quite well in past years. USOCKET authors (at least me) want to support as
> most versions of SBCL as possible.  This means, if we ask SBCL to add all
> necessary support to make things on usocket side become trivial, then we will
> loose support for older SBCL versions.  Sometimes we have to do some dirty
> work (all around SBCL backend code) to detect if a "feature" exist in a SBCL
> version...

While you can try to support as many versions as possible, by using
eg. SB-UNIX:FAST-SELECT you're virtually guaranteeing that at some
unspecified date an SBCL update will break usocket. (Sooner or later
SB-UNIX:SELECT will probably go away and be SB-UNIX:FAST-SELECT will
be renamed SB-UNIX:SELECT. For that matter, because SB-UNIX is one of
the more common causes of "things break due to an SBCL update because
someone used undocumented internals", we might rename the whole
package something less tempting.

Of course it's unrealistic for usocket to stop using stuff it has
grown up using tomorrow... but I think trying to support old SBCL
versions indefinitely in future usocket releases is a failing
strategy. The manpower to take write and maintain the different
versions just isn't there.

I would suggested that usocket should happily use as new SBCL versions
as it wants, and tells users of older SBCL versions to either update
SBCL not update usocket... (Or donate their time or money to maintain
the temporal portability if they really must be able to use new
usocket releases with old SBCL versions.)

As for what SBCL can do to support usocket better:

Generally speaking, if you tell us that you need X, and X is either
impossible or irritating to write using supported interfaces, we can
either provide you with a supported X or support necessary lower-level
interfaces.

X can be anything, but generally it is easier to expose low-level
functionality that gives you more rope than trying to get a high-level
interface right the first time.

If X is "a better networking substrate" ... it's going to take a
while. :) Easier things can happen very quickly, more specific ones
are typically easier.

Cheers,

 -- Nikodemus