[usocket-devel] Why rely on implementation specific network code?

[Erik Huelsmann]

On 1/5/07, Hedos <darkhedos at gmail.com> wrote:
> Why not make a CFFI library based around the C sockets library?
> Wouldn't that be easier? That would avoid running into some implementation
> limitations too.

CFFI doesn't work on ABCL (the java lisp). Also, CFFI - at least when
I started usocket - doesn't work on Windows. The sockets interfaces
for Allegro and LispWorks both work on windows as well as on Linux,
so, usocket runs on more platforms now than it would have if usocket
had been a CFFI binding.

>From the start, I have never excluded using FFI bindings though; quite
possibly it is necessary to resort to FFI bindings to make
get-/set-options working on some implementations.

As a last thing: The only way CFFI can know the values of certain
symbols (SO_REUSEADDR) is if there are header files installed on the
system trying to compile/run the files. I want to avoid that
requirement for basic use of the socket library.

Until now, there have been little implementation limitations that
could not be solved. I submitted some patches to ABCL and CMUCL (which
have been incorporated) to solve problems which I could not address on
the usocket end. All in all, the number of implementation limitations
has been small. Do you expect big problems with the route usocket is
currently taking?

bye,

Erik.