Everything is a distributed object

[Martin Drautzburg]

Hello all,

I've seen various attempts to add distributed computing capabilities on top
of an existing language. For a true distributed system I would expect it to
be possible to instantiate objects of a remote class or to subclass a
remote class and other stuff like this. My impression is that those things
are difficult when built on top of an existing language.

Since the paradigm "everything is an object" pays so well, I thought it
might be less painful to implement a distributed system from ground up,
starting with the paradigm: "everything is a distributed object".

Do you know if such a thing has been attempted with python, i.e. by hacking
the python core and add new capabilities to "object". Or do you think that
this is really a silly idea ?

 

[Hendrik van Rooyen]

Hello all,

I've seen various attempts to add distributed computing capabilities on top
of an existing language. For a true distributed system I would expect it to
be possible to instantiate objects of a remote class or to subclass a
remote class and other stuff like this. My impression is that those things
are difficult when built on top of an existing language.

Since the paradigm "everything is an object" pays so well, I thought it
might be less painful to implement a distributed system from ground up,
starting with the paradigm: "everything is a distributed object".

Do you know if such a thing has been attempted with python, i.e. by hacking
the python core and add new capabilities to "object". Or do you think that
this is really a silly idea ?

Google for pyro - Hendrik

 

[Nick Vatamaniuc]

See here:

http://wiki.python.org/moin/DistributedProgramming

-Nick V.

 

[Diez B. Roggisch]

Hello all,

I've seen various attempts to add distributed computing capabilities on top
of an existing language. For a true distributed system I would expect it to
be possible to instantiate objects of a remote class or to subclass a
remote class and other stuff like this. My impression is that those things
are difficult when built on top of an existing language.

Since the paradigm "everything is an object" pays so well, I thought it
might be less painful to implement a distributed system from ground up,
starting with the paradigm: "everything is a distributed object".

Do you know if such a thing has been attempted with python, i.e. by hacking
the python core and add new capabilities to "object". Or do you think that
this is really a silly idea ?

Pyro is pretty neat in that respect. And besides that, I think it is a
rather silly idea. In such an environment, immediately issues about
concurrency, connection failures and sychronous/asynchronous execution
arise, adding tremendously to the complexity of even the simplest of
tasks. And thus should be kept out of those simple tasks...

A natural integration of concurrency as in erlang, or with pyro, is a
good thing(tm), but not as base principle, IMHO.

Diez

 

[Steve Holden]

Hello all,

I've seen various attempts to add distributed computing capabilities on top
of an existing language. For a true distributed system I would expect it to
be possible to instantiate objects of a remote class or to subclass a
remote class and other stuff like this. My impression is that those things
are difficult when built on top of an existing language.

Since the paradigm "everything is an object" pays so well, I thought it
might be less painful to implement a distributed system from ground up,
starting with the paradigm: "everything is a distributed object".

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

Do you know if such a thing has been attempted with python, i.e. by hacking
the python core and add new capabilities to "object". Or do you think that
this is really a silly idea ?

I'd prefer to say "misguided" ;-)

regards
Steve

 

[Martin Drautzburg]

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.