[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Second draft of new Event API for Luasocket
- From: Diego Nehab <diego@...>
- Date: Mon, 28 Jun 2004 01:49:16 -0400 (EDT)
> 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...
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>
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).