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

[Erik Huelsmann]

On 1/5/07, Erik Huelsmann <ehuels at gmail.com> wrote:
> 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?

There's one more thing: I remember having looked very long for the way
to create a stream from a socket in Franz Allegro, but couldn't find
any. So, I decided that for the streamy sockets interface, the
implementations provide the best (only?) way to access the sockets.

bye,

Erik.