Alright, I''ve just checked in some new stuff. All of the unit tests in
experimental/EventMachine pass, and I''ve got some initial io tests that
are using paired sockets like Francis has done. (I never knew about
paired sockets, but it seems like a perfect fit for our testing. Very
cool!) If you look in the event tests you can also see the new stack
creation stuff that allows this:
LineHandler << HTTPHandler << SOAPHandler
I''d like to write some more tests on top of the basic IO to make sure I
haven''t broken anything with my changes, but after that it''s
up the
stack to test the client, server and our sample protocols on top. They
are all pretty thin so hopefully that won''t be too hard.
With the Machine::TCPServer, for example, this is what I''m shooting
for,
although its not quite there yet:
(NOTE: Francis this is a bit different from what I sent you. No need to
create the dispatcher from the outside. A bit cleaner hopefully...)
# Each protocol in the stack will be instantiated per connection. The
# order doesn''t make a difference since they all just subscribe to
# events, but most likely people will be thinking of it like this.
stack = LineHandler << HTTPHandler << SOAPHandler
TCPServer.new(host, port, stack)
or if you need to run custom initialization code you can pass a block
instead of a stack. This allows for sharing a single instance of a
protocol over a number of connections, for example:
server = MasterServer.new
# This block will be executed for each new connection created.
TCPServer.new(host, port) do |dispatcher|
LineHandler.new(dispatcher)
HTTPHandler.new(dispatcher, my_config)
SOAPHandler.new(dispatcher, my_config)
server.new_connection(dispatcher)
... # Anything else you need to do per connection
end
On top of this infrastructure we can create a variety of server classes
that encapsulate a full stack and make it really easy to implement
higher level services. It should be as easy to use something like an
event based DRB implementation, for example, as it is to use the current
synchronous one. For developers who are creating new servers and/or
protocols hopefully this mechanism for composing event based protocol
stacks will fit nicely. Ideas, comments, criticisms & suggestions are
definitely welcome.
I''m hoping to get the mini-HTTP stack running and tested tomorrow on
top
of the TCP{Client, Server}. What was the web performance tester you
used to check the stack?
I think the basic framework we''ve been putting together will make for a
nice all ruby release, but I don''t think we should be worrying about
supporting anything or maintaining API compatibility for a while still.
At least not until we have built a couple "real" apps on top of this
thing. Is that reasonable? I guess this is always an issue with
releasing early and often, but the benefits seem to outweigh the bad...
-Jeff