Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

[Dibyendu Majumdar <mobile@...>]

On Sat, 8 Feb 2020 at 22:10, Sean Conner <sean@conman.org> wrote:
>   The problem with libuv is that it's a framework, not a library [1].  And
> thus, you have to buy into its framework for how things should work.  And oh
> boy, does it have opinions on how things should work.  It supports:
>
>     Full-featured event loop backed by epoll, kqueue, IOCP, event ports.
>     Asynchronous TCP and UDP sockets
>     Asynchronous DNS resolution
>     Asynchronous file and file system operations
>     File system events
>     ANSI escape code controlled TTY
>     IPC with socket sharing, using Unix domain sockets or named pipes (Windows)
>     Child processes
>     Thread pool
>     Signal handling
>     High resolution clock
>     Threading and synchronization primitives
>
>   That's a *huge surface area*, but it almost has to support all those.  It
> needs threads to deal with reading/writing files [2], and if you have
> thrads, you need signal handling [3].  And if you are doing non-blocking
> socket operations, of course you'll need DNS resolution [4].
>

As I mentioned earlier in the chain, libuv's great strength it is used
in projects like Node.Js and Julia and therefore really battle tested
by large numbers of companies and people. Even if you dislike the
framework (and some people might dislike it as it builds objects in C
and requires really difficult event driven programming) - it is hard
to see how a replacement library could be justified. But libuv itself
does not deal with TLS or higher level interfaces such as http.

>   Then there's luv [11].  It too, is available via LuaRocks, but it appears
> to be its own echosystem, with it's own package manager [12] and everything.

Actually 'luv' is the barebones wrapper around libuv, whereas 'luvit'
is a Node.JS replacement for Lua, built on top of 'luv'/libuv. So the
package manager is not part of 'luv'.

'luv' exposes the libuv api which is why it is complex to use because
everything is asynchronous and read/write operations have to deal with
incomplete packets of data.
I am not sure you can hide this in a true event driven asynchronous library.

Regards
Dibyendu