Everything is a distributed object

Martin Drautzburg Martin.Drautzburg at web.de
Tue Oct 10 22:20:35 CEST 2006

Steve Holden wrote:

> Unfortunately the overhead of supporting distribution is way too high to
> want to invoke it between two objects living in the same process.

Well I was thinking along the lines of "object" and "proxy-object" where a
proxy object is a handle to a remote object. Sending a proxy-object back to
its original site would reconstruct the original object. So other then
checking if an object is a proxy or not there would be no overhead at all
for non-distributed computing.

Other issues that have been mentioned is network latency or network failure.
I can't really see how this is any different to any other kind of
distributed computing. It should all be a matter of which object lives on
which side of the wire. Of course you *can* build incredibly slow system
when everything is a distributed object, but I cannot see why it *has to"
be slow. And isn't premature optimization the root of all evil?

I believe in a way every distributed system can be seen as a distributed
object system. The main difference is that you have very limited choices
which objects live on which side and what you can send over the wire. In
X11 the DISPLAY is an object that lives on the remote site and you invoke
methods from the client program, which pass literal values, i.e. objects
that can be pickled and whose class is known on the other side. AFAIK fonts
are already a little more complex, because the client does not have to know
what a character looks like, but the Xserver does.

I am kind of confused by the existing tools to program distributed systems
(including pyro), because I find it difficult to figure out how far they
go. I always suspect that they are simply a variation of the "remote adder"
theme, where you can send two numbers and get the sum back.

That would be quite a limited thing IMHO because that would require both
parties to have a common understanding about numbers. While this is
certainly easy to achieve, it leads to a lot of undesired shared knowledge
when things become a little more complex.

So I always wonder

(1) Is it possible to send an object as a parameter?
(2) Can I still do this if the class of this object is only known on one
side of the wire?
(3) Can I instantiate an object of a remote class locally?
(4) Can I subclass a remote class?

I believe pyro can do (1) and none of the rest.

More information about the Python-list mailing list