Re: LuaSocket 3.0

[diego@...]

Hi,

> 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.

I agree, but I can't do magic. If there is an object on
which we can't issue an assynchronous I/O request and then
receive the notification through the same mechanism as the
other objects (say, a database connection), that's too bad.
It would be possible to simulate the behavior using multiple
threads, but I don't think this is up to LuaSocket. I will
provide the mechanisms, not the implementation.

> 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.

I thought about this. The library will feel like a general
I/O library, but my guess is that it won't be used as such.
I will do my best to implement a general API that supports
most of what you described, but this is just because I can,
not because I feel I have to.

As I said, on Linux and Mac OS X, I honestly don't know if
you can put *any* file descriptor in non-blocking mode,
issue a resquest, and receive a proper notification later.
If this works, fine, it will all work by magic.  Otherwise,
there is not much I can do.

Also, with a set of two-line functions, it should be
possible to simulate pretty well the LuaSocket 2.0 using the
new API. There would be no point in using the old library
for new projects (assuming it is not terribly slower when
you use 1/2 sockets only).

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

As soon as I have one. :)

[]s,
Diego