Hi
What is the way to specify that only some methods on an object
exposed via Drb can be accessed? Reading the source, I found the
INSECURE_METHOD array, so this is what I’m doing now:
module Foo
some methods
end
class Bar
include Foo
I want Bar’s own methods to be available via DRb, but not the
ones from Foo
def initialize
Foo::instance_methods.each { |meth|
DRb::DRbServer::INSECURE_METHOD << meth.intern
}
end
some methods
end
Is this the only way to do this or is there something cleaner?
Thanks,
Andre
Andre Nathan wrote:
Hi
What is the way to specify that only some methods on an object
exposed via Drb can be accessed? Reading the source, I found the
INSECURE_METHOD array, so this is what I’m doing now:
Declaring them private works for me, as below:
module Foo
some methods
end
class Bar
include Foo
I want Bar’s own methods to be available via DRb, but not the
ones from Foo
Foo.instance_methods.each do |m|
private m
end
end
Or, simpler, you can just make them private in Foo, if that makes sense
for other users of Foo.
Joel VanderWerf said:
Declaring them private works for me, as below:
Foo.instance_methods.each do |m|
private m
end
But that would make them unavaible for local use (my original idea was
something like “you can use it locally, but not through the network”.
Would that be considered bad design? I mean, if a class is to be used
via DRb, should it be used only via Drb?).
Or, simpler, you can just make them private in Foo, if that makes sense
for other users of Foo.
I didn’t know modules could have private methods (or maybe I forgot…)
I’ll have a look at that.
Thanks,
Andre
If you only want methods available locally, then you should probably put a
proxy class on DRb that exposes everything but those methods.
-austin
···
On Thu, 1 Jan 2004 08:23:14 +0900, Andre Nathan wrote:
Joel VanderWerf said:
Declaring them private works for me, as below:
But that would make them unavaible for local use (my original idea was
something like “you can use it locally, but not through the network”.
Would that be considered bad design? I mean, if a class is to be used via
DRb, should it be used only via Drb?).
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.12.31
* 18.44.48
Would including DRbUndumped help? This forces a DRbObject to be created
on the remote side, and makes sure all of the work happens on the side
of the connection that created the object.
···
Andre Nathan (andre@digirati.com.br) wrote:
But that would make them unavaible for local use (my original idea was
something like “you can use it locally, but not through the network”.
Would that be considered bad design? I mean, if a class is to be used
via DRb, should it be used only via Drb?).
–
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
Austin Ziegler said:
If you only want methods available locally, then you should probably
put a proxy class on DRb that exposes everything but those methods.
Hi Austin
By ‘proxy class’ you mean something like this:
class Foobar
def foo
puts ‘foo’
end
def bar
puts ‘bar’
end
end
class FooProxy # only ‘foo’ exposed
def foo
Foobar.new.foo
end
end
And then expose FooProxy via DRb?
Excuse my nubyness… :-/
Andre
Eric Hodel said:
Would including DRbUndumped help? This forces a DRbObject to be created
on the remote side, and makes sure all of the work happens on the side
of the connection that created the object.
I believe this wouldn’t solve the problem for local access to the methods.
If they are declared private, a local instance of the class wouldn’t be
able to use them. Unless I misunderstood what you meant…
Andre
More or less. You’re want to do FooProxy more like:
class FooProxy
def initialize
@foo = Foobar.new
end
def foo
@foo.foo
end
end
However, most of the hard work of doiing this sort of thing has
actually been provided in Ruby through DelegateClass and
SimpleDelegate. You can find information on these in the Pickaxe
book.
-austin
···
On Thu, 1 Jan 2004 10:03:08 +0900, Andre Nathan wrote:
Austin Ziegler said:
If you only want methods available locally, then you should
probably put a proxy class on DRb that exposes everything but
those methods.
By ‘proxy class’ you mean something like this:
class Foobar
def foo
puts ‘foo’
end
def bar
puts ‘bar’
end
end
class FooProxy # only ‘foo’ exposed
def foo
Foobar.new.foo
end
end
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.12.31
* 23.03.30
Eric Hodel said:
Would including DRbUndumped help? This forces a DRbObject to be created
on the remote side, and makes sure all of the work happens on the side
of the connection that created the object.
I believe this wouldn’t solve the problem for local access to the methods.
If they are declared private, a local instance of the class wouldn’t be
able to use them. Unless I misunderstood what you meant…
Use include DRbUndumped instead of declaring methods private.
Let me re-quote you:
But that would make them unavaible for local use (my original idea was
something like “you can use it locally, but not through the network”.
Why do you want to do this?
Is it because certain operations must be performed only on one side of
the connection, or is it because certain operations are forbidden?
If its the former, DRbUndumped is the correct solution.
If its the latter, I would look at what including DRbUndumped does, you
can probably extend it to create your custom proxy object in a
straightforward matter, something like:
class Dangerous
include MakeSafe
safe_methods :foo, :bar
…
end
···
Andre Nathan (andre@digirati.com.br) wrote:
–
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
Austin Ziegler said:
However, most of the hard work of doiing this sort of thing has
actually been provided in Ruby through DelegateClass and
SimpleDelegate. You can find information on these in the Pickaxe
book.
Great, I’ll have a look at it. Thanks a lot!
Andre