Folks, have a look at some new stuff in the pure Ruby branch (experiments/machine). Jeff has added support for signals. I just added support for "event-routing," which is basically publish-subscribe. There is a new EventDispatcher called EventRouter. It accepts subscriptions for particular event types and distributes those events to the subscribers. Next I''ll add a thread-pool to EventRouter, and a proxy so it can subscribe to events originating in other processes. This is going rather well. As soon as we''re all comfy with the APIs we need to start writing docs and use cases, and get this puppy released. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20060527/3d87d73a/attachment.htm
Francis Cianfrocca wrote:> Folks, have a look at some new stuff in the pure Ruby branch > (experiments/machine). > > Jeff has added support for signals. > > I just added support for "event-routing," which is basically > publish-subscribe. There is a new EventDispatcher called EventRouter. It > accepts subscriptions for particular event types and distributes those > events to the subscribers. Next I''ll add a thread-pool to EventRouter, > and a proxy so it can subscribe to events originating in other processes.So is EventRouter basically just a general purpose EventDispatcher in the shape of a class so we can instantiate? What is subscribing versus adding and handler for a specific event type?> This is going rather well. As soon as we''re all comfy with the APIs we > need to start writing docs and use cases, and get this puppy released.Thanks for putting in the protocol stuff. I''m working on it now. I also added a few things like the ChangeLog, credits etc. Not really up and running yet, but I''m going to commit my changes so we can be working on the same branch... Tomorrow I should have a simple protocol stack put together in a couple different ways. Ciao, Jeff
Jeff, I split the EventRouter class into EventPublisher and EventSubscriber. Cf. test/router_test.rb for examples. EventSubscriber is an EventDispatcher like any other. It''s built analogously to Timeouts (do we want to rename them Timers?) and EventableIOs. You mix EventSubscriber into any class and tell it what events to listen for (in the constructor and/or by calling #subscribe). It then sits and spins until someone else fires an event of the specific type. EventPublisher can be mixed into any class. It adds #publish_event, which is exactly like #send_event except that it mixes #send_reply into the event which is being sent. This allows event handlers in EventSubscriber objects to fire events which will be received by the original publishers. (Of course I don''t particularly care for modifying a user object like this on the fly.) Perhaps you can improve on this structure. The nice thing about it is that it was done without any changes to any other modules (except for one line in reactor). It would be nice to preserve this orthogonality.>>>What is subscribing versus adding and handler for a specific event type?"Sending an event" is something that happens on the same object which will process the event- you need a reference to that specific instance. "Publishing an event" identifies only the type of the event, and an internal algorithm *chooses* one or more handlers from among those objects that have expressed interest in ("subscribed to") the particular event type. There''s no explicit coupling between the ultimate sender of the published event and the recipient which handles it. Does that explanation make any sense to you? What I''ve left out for now is the notion of "broadcasting" to all subscribers of an event, and a maximum time to wait for a subscriber. Looking forward to seeing your work on the protocol handlers. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20060528/02c1dcf6/attachment.htm