Re: LuaSocket 3.0? (was Re: A proposal for faster userdata type checking)

[Duck <duck@...>]

>We are shooting for an API that behaves like the IOCP API from Windows, 
>but simpler to use.  Using kqueue on BSD, IOCP on Windows, epoll on 
>Linux.

Sounds excellent.

I would add my voice to those who are urging that a LuaSocket 3 object 
should be able to handle (within reason, of course) any read-writeable 
object, not just IP sockets, on any supported platform.

Being able to throw files, named pipes, sockets etc. into the mix is IMO 
vital if you want to write something like a TCP server which does anything 
more than trivia. With co-operative multitasking you can't afford to have 
any point at which something which isn't using a socket might block. (Even 
uncontroversial I/O, such as writing one line to a log file, is 
potentially dangerous -- the file might be on a remote NFS server for all 
you know.) So IMO, _all_ I/O must be handleable through the same asynch 
API, or it's going to have an unconquerable weak spot.

Incidentally, it sounds as though what you are building isn't really 
LuaSocket 3, but LuaAsynCore 1, so it seems as though there is a case for 
naming it as a new library, and keeping LuaSocket 2 as an alternative, and 
more traditional, socket-specific API for those Lua users to whom it's 
sufficient, more comformatable, etc. In other words, reflect the 
difference in nomenclature as well as implementation.

When can we get at a pre-release build :-)