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

[pocomane <pocomane_7a@...>]

On Tue, Jan 28, 2020 at 1:35 AM Sean Conner <sean@conman.org> wrote:
>   I don't have Windows, so I can't say for sure how Windows IOCP works, but
> I'm hoping they can fit into the scheme I've outlined above.  Thoughts?
> Comments?  Criticisms?
>
>   -spc

I want to clarify a point: is this API proposed as a "Generic event"
API (not just a "File/socket" one)? I think that such API is crucial
for the modularity, i.e. if I will write a C module that interact with
a USB gamepad, I would like to put "Handler objects" in the same Set
to monitor both gamepad and sockets contemporary.

Without this, any modularity is illusionary.

I am not discussing the implementation here, if there is the need for
a "Fake file descriptor" internally, it can be done [1]. In this
spirit I would substitute "File descriptor" and "_tofd" with something
else. I propose this also because the API should make sense in systems
that do not use the file descriptor for event notification too, like
windows.

Another comment: I have some doubt about the resulting event list.
Probably events from different sources will be dispatched to different
code, so the following format could be better (practically a mix of
your own and the luaposix one):
{
  [objA] = {
    read = true,
    write = false,
   ... -- all field always present
  }
  ... -- Object field is missing if there is no notification for it
}

Moreover, I think that keeping it simple is more valuable than your
trick to substitute an optional var to Obj. If a user code really need
it, it can keep the map in a table by its own.

pocomane

[1] However, probably every lua-side standard specification will need
some c-side specification. And probably, some internal details have to
be exposed there.