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

[Sean Conner <sean@...>]

It was thus said that the Great Russell Haley once stated:
> On Fri, Jan 24, 2020 at 3:45 PM Sean Conner <sean@conman.org> wrote:
> > It was thus said that the Great Michal Kottman once stated:
> > > 
> > > I must be missing something obvious, but what is wrong with LuaSocket?
> >
> >   I also think the API could be cleaner.  I haven't looked too deeply into
> > the differences between LuaSocket, luaposix (which include a networking API)
> > and my own org.conman.net module, but from what I've seen, they are all
> > quite different in their apprach, with the first two being more C'ish, and
> > the latter being more Lua'ish (in my opinion).
> >
> >   But before we get there, I want to discuss wrappers for select().  Soon.
> 
> The C library for Cqueues contains a proper event driven library written
> ground up by William Ahern for use in Lua. It works with poll, epoll,
> kqueues and whatever-the-heck Solaris uses. It *doesn't* support IOCP for
> Windows. If we can add IOCP support then we have a superb socket library
> for all platforms. I found a library stuffed inside another project that
> claimed to be an epoll wrapper for IOCP. I can dig the info up if you like.

  I want to keep the event driver module from the network module.  Granted,
event drivers are mostly used for network applications, but there are times
when you need them sans networking, such as dealing with character devices
like serial ports or terminal IO.

  A module like Cqueues is more of a framework than a library.  If there was
a separate event module, then frameworks like Cqueues, lua-ev or turbo could
gain access to the best underlying event structure for a given operating
system.  Of the five non-framework event modules I"ve found, there's a bit
of overlap, but no real consensus.  I've avoided looking at frameworks, but
I think I need to look at them as well.

  I know nothing about Windows IOCP, but I suspect it might be based upon a
different abstraction than Unix select()/poll()/epoll()/kqueues().  My hope
is that they aren't so different that it makes a generic event driver for
Unix and Windows nearly impossible.   If you can look into that, I would
appreciate it.  The API I'm currently leaning towards is something like:

	err = set:insert(fileorsock,"rw"[,val])
	err = set:update(fileorsock,"r")
	err = set:remove(fileorsock)
	events[,err] = set:events([timeout])

	items = #set -- number of items in current set

  For insert() and update(), the second paramter is a string describing the
events you are interestd in, and the four common ones among the POSIX
systems are:

	r - you can read data now
	w - you can now write data
	p - there is priory data (I don't think this is used much in TCP)
	e - there is an error 

  events() will return an array, where each item is a table with the
following items:

	{ 
	  event = 'read', -- or 'write' or 'priority' or 'error' 
	  obj   = val -- given in insert(), or fileorsock if not
	}

but I haven't fully thought this out though, as there are some issues that
need to be addressed first.  I'm just saying where my thoughts are going
right now.

  -spc