Couldn't you use DRuby (require 'drb')? That's what I do in my Rails
program. In the 2nd (distributed) server, I spawn a thread immediately
upon request to the the work, and then return right away to the web
process, which returns immediately to the browser.
I don't have callbacks, but I imagine it would be dead-easy to have the
2nd server take a request ID from the 1st, then just call back using a
DRuby call just like the 1st, pushing back the original request ID.
This is the "asynchronous completion token pattern" as described by
Schmidt. Here's the (very verbose) write-up ...
http://www.cs.wustl.edu/~schmidt/PDF/ACT.pdf
You certainly could use the asynchronous completion token pattern, but
I think if you compared implmenting that vs. implementing it using an
event-driven framework -- even using Schmidt's EMIS Management system
example, you'd see that the event-driven framework is not only a lot
less work, much less error-prone and easier to debug, but also
higher-performance (of the three advantages, I actually consider the
performance to be least important).
I know that this type of proclamation sounds like pie-in-the-sky
bigotry against well-established practices, but I'm not kidding: once
you go event-driven, you never go back.
If there is someone already working on a libasync equivalent in Ruby,
I'd love to pitch in. If not, I'd love to think that I could start one
up.
Python's twisted is very nice, but they've implemented way up the
stack. I'd settle for something as dead simple as a generic
event-driven TCP/UDP programming framework.
Lenny
You might want to take a look at the Myriad framework [1] written by Zed Shaw. I'm not so sure it is fully functional because I believe it depends upon his Ruby/Event framework that he abandoned. Perhaps you'd want to continue his work.
[1] http://zedshaw.com/projects/myriad/index.html
···
On Jan 24, 2006, at 9:38 AM, alenpeacock@gmail.com wrote:
You certainly could use the asynchronous completion token pattern, but
I think if you compared implmenting that vs. implementing it using an
event-driven framework -- even using Schmidt's EMIS Management system
example, you'd see that the event-driven framework is not only a lot
less work, much less error-prone and easier to debug, but also
higher-performance (of the three advantages, I actually consider the
performance to be least important).
I know that this type of proclamation sounds like pie-in-the-sky
bigotry against well-established practices, but I'm not kidding: once
you go event-driven, you never go back.
If there is someone already working on a libasync equivalent in Ruby,
I'd love to pitch in. If not, I'd love to think that I could start one
up.
Python's twisted is very nice, but they've implemented way up the
stack. I'd settle for something as dead simple as a generic
event-driven TCP/UDP programming framework.