[usocket-devel] Why rely on implementation specific network code?
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.
On 1/5/07, Hedos <darkhedos@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.
From the start, I have never excluded using FFI bindings though; quite
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. 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.
On 1/5/07, Erik Huelsmann <ehuels@gmail.com> wrote:
On 1/5/07, Hedos <darkhedos@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.
participants (2)
-
Erik Huelsmann -
Hedos