On 5/17/06, Madan Manoharan <madan.manoharan / gmail.com> wrote:
> (1) Is there a way for me to make asynchronous calls in DRb; in other words,
> am I overlooking that functionality?

Yes. It is actually more simple that you think (Ruby is more magic
that most realize). The key is that it doesn't need to be in DRb. The
first thing I thought of when I saw async. + DRb in the title was a
language called Io [1]. It is interesting in many ways (though under
heavy work still). There is one point of interest that is useful in
this case. Io supports something called Futures and also plain
asynchronous calls:

obj := Object clone do (foo := method("Hello" println))

obj foo #=> both print and return "Hello"

obj @foo #=> print "Hello" when forced or when the scheduler activates
it and return a Future representing the return value (or exception)

obj @@foo #=> same as @foo but w/o a return value (get nil back in in
call failure).

I should also note another mechanism not in Io [2] that is very
similar to futures. Promises provide the same feature as a future but
will only execute when the value is used (i.e. a forced block) while
the typical notion of a future is something that will eventually
happen on its own.

Ruby does not have any of these in the standard library BUT they can
easily be built (and have -- use google or check out some of
MenTaLguY's work on this topic). The key is to keep the mechanism
transparent or at least clean. Io can manage something that might as
well be transparent to most people (some exceptions but even those are
few and out of scope here). Ruby can't be quite as nice [3]. That is a
far cry from defeat though. Of course if should mention that async.
calls w/o significant return values is easy to make clean.

The key feature of the implementation would have to be the use of
threads since Ruby already uses select() internally (maybe in the
future it will use libevent to boost performance). Again, some work
has been done in related areas. I would highly recommend you check it
out.

> (2) If there is no asynchronous call capabilities in DRb, why was that not
> added when it could have been easily done (not call client.send_reply and
> recv_reply)? Is there a technical reason for it?

There are so many things we could add to DRb. The problem is that
negates one of DRb's strengths: simplicity. Adding things that aren't
a required part of DRb is overload. However, _if_ your requirements
are *simple* maybe there could be a simple plugin that could be used
with a quick and simple optional require. My personal feeling is that
DRb could probably shed some of its current weight [4] and focus a
little more on a clean way people can plug and play customizations of
their own [5].

Brian.

[1] http://iolanguage.com/
[2] Yet. It is a very simple patch to its "prelude" code as I call it.
Maybe I will submit one once I get my dev. laptop back from repair
(has all my Io work on it unfortunately).
[3] No Object#become or the like -- evil.rb provides this but it still
won't work on immediates. Proxy objects or explicit value retrieval
(like you see in Java's concurrency interfaces and Ruby threads) would
probably the main candidates.
[4] The only thing that is weighty to me is that is ACLs. There might
be a better way to factor that out and provide a more complete and
generic ACL library. Of course this is only me speaking. I am sure
there are those that use DRb ACLs all the time.
[5] My more general rant is that we shouldn't try to change the
standard library to a all feature circus. I think there is reason to
be potent but not bloated.