Re: Second draft of new Event API for Luasocket

[Diego Nehab <diego@...>]

Hi,

> And here is the stuff that will probably make Diego unhappy:

Damn right. :o)

I appreciate the effort you are putting on this. I am trying to catch up
but right now I am busier than I wanted to be.  Let me for now state
some things I would like to be considered for the event scheme to
respect the LuaSocket philosophy:

    1) Minimum functionality of the event scheme should work the same
       way regardless of operating system (seems obvious);
    2) Using the event scheme should be optional (not everyone
       needs to go fancy);
    3) Being able to do system specific stuff, such as waiting on a
       thread, on a message queue, or the face of the moon, should be
       only possible (1 and 2 take precedence).

I admit LuaSocket is biased towards the Unix way of doing things.  This
is my fault: it's what I tried first and it seemed to work fine.  I
have, however, put some effort in making the code abstract enough that
one could completely replace the underlying implementation of
I/O with not too much pain. Of course, I didn't have changes of this
magnitude in mind...

\begin{curse}
After all, if Unix programmers want to access their system specific
goodies and Windows programmers want to be able to use idiosyncratic I/O
schemes, we might as well forget LuaSocket and run toLua on <*.h>
\end{curse}

There are a variety of options between having an almighty event scheme
(with a LuaSocket that depends on it for everything) and having
LuaSocket as it is (with a cheesy select function).  It's even possible
to have it that once a user runs 'event = require"event"' some functions get
replaced and change the way things work.

Here is the deal: I would be more than happy to fix LuaSocket so that
its abstraction layer is good enough to support weirder I/O models.
However, I am not about to scratch the peasant's way of doing I/O.
I have not been convinced the trade is to our advantage (yet).

[]s,
Diego.