Email list hosting service & mailing list manager

networked application with libuv Amirouche Boubekki (12 Oct 2020 06:52 UTC)
Re: networked application with libuv Lassi Kortela (12 Oct 2020 08:06 UTC)
Re: networked application with libuv Amirouche Boubekki (12 Oct 2020 12:29 UTC)
Re: networked application with libuv Lassi Kortela (15 Oct 2020 18:44 UTC)
Re: networked application with libuv Amirouche Boubekki (17 Oct 2020 09:16 UTC)

Re: networked application with libuv Lassi Kortela 15 Oct 2020 18:44 UTC

> Yes. I did not come to this suggestion lightly. The thing is relying
> on raw POSIX or Windows API is error prone

That's definitely true. Even for those who don't use it, its source code
and issue tracker is excellent documentation.

> and does not work all the time because you need errno.

> The advantage of libuv is that a) it does not expose errno

What does this mean?

> b) it is
> portable across many platforms, runtimes (windows, POSIX, musl, glic),
> and scheme implementations.

Definitely an asset. And libuv doesn't seem to have any dependencies on
third-party libraries.

>>> If we have cross platform bindings for that it will allow us to create
>>> a couple portable implementations for on-going pre-srfi like http, p2p
>>> and cell-terminal. Possibly others like database drivers?
>>
>> All of those are useful for sure. But should probably not depend on
>> libuv specifically.
>
> I am sure you know that sample implementations are useful to drive the
> specification of useful libraries forward, and give a baseline that
> may work on many schemes. libuv will allow us to build and test
> network libraries on many schemes.

Definitely a useful implementation tool, as long as the interfaces
specified in SRFIs also work without libuv. We probably can't convince
most/all Scheme implementations to ship it; a few don't even use C.

> I am not sure what I am supposed to do? I suggest I will work on libuv
> bindings, that work can benefit many Scheme implementations especially
> those that support r6rs-pffi. Gambit in particular, might not benefit
> from those bindings directly, higher level libraries will abstract the
> uv-specific bits, so it will be useful eventually.
>
> Guile can benefit from libuv bindings even if they have their own
> socket-port machinery. Loko is not interested in C bits.

I'm not familiar in detail with the other implementations; you know
better than I do.

> AFAIU, CML based on ports is compatible with libuv when you have custom ports.
>
> Consider the libuv bindings just a chime to bring as much Scheme
> implementation onboard the network party.

Sounds excellent.