From: Robert Klemme <bob.news@...>
Date: 2004-02-09T10:42:54+09:00
Subject: Re: Removing methods from DRbObject


"Tim Bates" <tim@bates.id.au> schrieb im Newsbeitrag
news:4023592E.9090409@bates.id.au...
> My application is using DRb extensively in support of its client-server
> model. Ideally I would like to have the remote objects in the client
> scripts appear exactly as they would if they were local. All my data
> objects include DRb::DRbUndumped so that only references are passed
> across the network, as the objects' code needs to run on the server
> (database access etc). Unfortunately, DRb::DRbObject defines a bunch of
> methods which it doesn't really use, such as ==, ===, <=> etc; but
> because it defines them, calls to them don't get proxied to the server.
>
> The Criteria module has in it a neat little bit of code that looks like
> this:
>
>    mask = ["__send__", "__id__", "inspect", "class", "is_a?", "dup",
>            "instance_eval"];
>    methods = instance_methods(true)
>    methods = methods - mask
>
>    methods.each do |m|
>      undef_method(m)
>    end
>
> This removes all methods from the class except those in mask.
> Something like this in DRb::DRBObject, with an appropriate mask list,
> would be really useful, because at the moment, if I have two DRbObjects
> which represent the same object on the remote side, the == method still
> returns false because of the way DRbObject defines == (the default way,
> if it's not exactly the same object they're not equal).
>
> Therefore I have three questions:
> 1) Is this a reasonable change to make?
> 2) What is an appropriate mask list to use for DRb::DRbObject?
> 3) Can I get this change into the core library?

I'll prefer to raise another issue: usually it is not a good idea to
reference masses of instances remotely.  Thies yields hight network load
since lot's of methods are not invoked locally but remotely.  This can
degenerate to a degree where an application is no longer usable.  Did you
verify that your application does not suffer from this performance
degeneration?  If not, I'd first verify that usig lots of instances
remotely is practical.  While transparent distribution of instances sounds
like a good thing, a typical application using distribution should / must
be aware of the distribution in order to do things efficiently.  In your
case it *might* be better to transfer an array or hash of data objects to
the client, work with then and send them back afterwards.

Just my 0.02EUR...

Kind regards

    robert