# PyPy[distribution-newattempt]

PyPy[distribution-newattempt]
news getting-started documentation svn issues contact EU/project

# Distribution:

This is outcome of Armin's and Samuele's ideas and our discussion, kept together by fijal.

# The communication layer:

Communication layer is the layer which takes care of explicit communication. Suppose we do have two (or more) running interpreters on different machines or in different processes. Let's call it local side (the one on which we're operating) and remote side.

What we want to achieve is to have a transparent enough layer on local side, which does not allow user to tell the objects local and remote apart (despite __pypy__.internal_repr, which I would consider cheating).

Because in pypy we have possibility to have different implementations for types (even builtin ones), we can use that mechanism to implement our simple RMI.

The idea is to provide thin layer for accessing remote object, lays as different implementation for any possible object. So if you perform any operation on an object locally, which is really a remote object, you perform all method lookup and do a call on it. Than proxy object redirects the call to app-level code (socket, execnet, whatever) which calls remote interpreter with given parameters. It's important that we can always perform such a call, even if types are not marshallable, because we can provide remote proxies of local objects to remote side in that case.

XXX: Need to explain in a bit more informative way.

## Example:

Suppose we do have `class A` and instance `a = A()` on remote side and we want to access this from a local side. We make an object of type `object` and we do copy `__dict__` keys with values, which correspond to objects on the remote side (have the same type to user) but they've got different implementation. (Ie. method calling will look like quite different).

## Even cooler example:

Reminding hpk's example of 5-liner remote file server. With this we make:

    f = remote_side.import(open)
    f("file_name").read()

## Implementation plans:

We need:

- app-level primitives for having 'remote proxy' accessable
- some "serialiser" which is not truly serialising stuff, but making sure communication will go.
- interp-level proxy object which emulates every possible object which delegates operations to app-level primitive proxy.
- to make it work....