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