Hi Anton,
in theory, it's a noble target. Problem is that there are inherently
non-portable things to consider, e.g. how does iolib handle control-c?
So for each supported implementation, there needs to be a bit of code
that cuts directly into the lowest level of the host lisp environment.
It seems doable though. But still, cffi dependency can be undesirable
so the original (non-iolib) usocket is still a better solution in those
cases.
Also, usocket has heavy posix bias. Ideally, it would be better to
identify possible use-cases and create and api that would allow to
embrace any of them. For example, the idea of wait-* function makes
usocket inherently non-portable to non-posix systems. I am still
searching for such unifying all embracing io api:-)
Cheers,
Tomas
On 06/24/2013 12:18 PM, Anton Vodonosov wrote:
I also want to highlight the advantage of IOLib based sockets.
The underlying socket API provided by most of the OSes today is the same - BSD
sockets.
Various Lisp implementations multiply this basic API by proving their own,
distinct lisp versions of socket APIs.
On top of it we create a compatibility layer, to unify the API.
OSes: 1 API "BSD sockets" => Lisp impls: 10 APIs => usocket 1 API.
If we use some FFI library like IOLib to access OS socket APIs we avoid all
these redundant 10 intermediate APIs.
Best regards,
- Anton
