Eventmachine talk - May 2006 - Responses to Jeff Rose

1) In the great-minds think alike department, I''ve already added Class
support for protocol handlers. The following is now possible:

class EchoServer < EventMachine::Connection
  def initialize
    start_tls
    # other per-connection initialization
  end
end

EventMachine.run {
  EventMachine.start_server "1.2.3.4", 8900, EchoServer
}

As regards support for pluggable protocols, I think we will certainly have
to do something like that. The current EventMachine design handles only
network traffic and timers, so the API elides the underlying work of setting
up protocol factories, etc. That''s not going to be good enough when we
support a lot of other kinds of events.

2) C++: it''s just easier to write in C++ than C, but now that the basic
core
is sound, I think we should consider a backport to straight C. If you look
at the source code, the ruby interface is contained entirely in rubymain.c.
There is another, more generic interface in cmain.c, so EventMachine can be
used with any language, not just Ruby. The software design uses polymorphism
to support the different kinds of events (server sockets, client sockets,
datagram sockets, timers) but that''s not a serious requirement. I think
this
is worth doing. Windows: Eventmachine was written and tested on Unix and
Mac. I never seriously considered a Windows port until people showed
interest. There is no issue with C++ in Windows. The problem is the
networking, threading and system calls, which differ from Unix in many ways.


Pure ruby implementation: I''m not sure we can make this work. I could
be
wrong. It''s probably worth a try.

3) The whole idea with eventmachine''s protocol handlers is that they
will be
called by the framework in a manner that appears asynchronous to the
application programmer. I think the "deferred" thing in Twisted is
exposing
an abstraction to the programmer that should be hidden. On the other hand,
I''m really intrigued by the multiple-handlers idea. There are actually
two
levels going on here: there are discrete system events, and at a higher
level, there are protocols which encapsulate series of events. The current
eventmachine sort of conflates the two, by providing the "protocol
handler"
model for network traffic and the discrete model (complete with blocks) for
timer events. It needs to be more generic, and we should explicitly move the
protocol handlers up to a higher level. You theoretically should be able to
create your own protocol handler from the discrete network events, which is
currently hidden.

4) Event loops: I don''t have anything meaningful to say about that yet.
What
else would we need to support in addition to GTK and Windows?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20060510/1edfab99/attachment.htm

Francis Cianfrocca wrote:
> 1) In the great-minds think alike department, I''ve already added
Class
> support for protocol handlers. The following is now possible:
>
> class EchoServer < EventMachine::Connection
>   def initialize
>     start_tls
>     # other per-connection initialization
>   end
> end
>
> EventMachine.run {
>   EventMachine.start_server " 1.2.3.4 <http://1.2.3.4/>",
8900, EchoServer
> }
>
> As regards support for pluggable protocols, I think we will certainly
> have to do something like that. The current EventMachine design handles
> only network traffic and timers, so the API elides the underlying work
> of setting up protocol factories, etc. That''s not going to be good
> enough when we support a lot of other kinds of events.
Cool, looks good.
> 2) C++: it''s just easier to write in C++ than C, but now that the
basic
> core is sound, I think we should consider a backport to straight C. If
> you look at the source code, the ruby interface is contained entirely in
> rubymain.c. There is another, more generic interface in cmain.c, so
> EventMachine can be used with any language, not just Ruby. The software
> design uses polymorphism to support the different kinds of events
> (server sockets, client sockets, datagram sockets, timers) but
that''s
> not a serious requirement. I think this is worth doing. Windows:
> Eventmachine was written and tested on Unix and Mac. I never seriously
> considered a Windows port until people showed interest. There is no
> issue with C++ in Windows. The problem is the networking, threading and
> system calls, which differ from Unix in many ways.
Well, rather than develop in parallel for everything it might be nice to
stick to *nix (linux, OS-X) at least while we hammer things out, and
then maybe a windows guru will jump in to add support once it looks
compelling :-)  I''m fine with either C or C++ at this point, but
hopefully whatever goes on top of this can all be done in ruby.  At
least until performance would require something faster...
> Pure ruby implementation: I''m not sure we can make this work. I
could be
> wrong. It''s probably worth a try.
Yeah, I was warned that it wasn''t easy to do non-blocking I/O with the
current networking in ruby.  Is it something fundamental with the
design?  Any idea if that is changing in the next release?  Maybe we can
propose some changes and/or submit some patches to make this happen.
Having a 100% ruby implementation would really help for getting into the
project.
> 3) The whole idea with eventmachine''s protocol handlers is that
they
> will be called by the framework in a manner that appears asynchronous to
> the application programmer. I think the "deferred" thing in
Twisted is
> exposing an abstraction to the programmer that should be hidden. On the
> other hand, I''m really intrigued by the multiple-handlers idea.
There
> are actually two levels going on here: there are discrete system events,
> and at a higher level, there are protocols which encapsulate series of
> events. The current eventmachine sort of conflates the two, by providing
> the "protocol handler" model for network traffic and the discrete
model
> (complete with blocks) for timer events. It needs to be more generic,
> and we should explicitly move the protocol handlers up to a higher
> level. You theoretically should be able to create your own protocol
> handler from the discrete network events, which is currently hidden.
Agreed.  It also seems like unifying the model makes the event handling
loop pretty simple.  You just have a queue of events, and each object
has its own handlers attached.  On top of that we can support whatever
kind of semantics seem right for the situation.  Implementing a method
does seem nice for protocols... although I''d probably want to still use
blocks for timeouts & error handlers...
> 4) Event loops: I don''t have anything meaningful to say about that
yet.
> What else would we need to support in addition to GTK and Windows?
I doubt it''s very different from toolkit to toolkit so people can add
support for their system of choice as time goes on.  I''d probably just
use GTK also.

You have this thing under source control somewhere?