Open Stack

> I was just wondering about the magic rpc part.
> 
> It might be controversial but is a decorator the right way to go?

To summarize the discussion we just had on IRC: yes. The decorator
provides us the simple per-method indirection needed to call out to the
actual implementation via RPC if our service is marked as
should-be-remote. Function decorators are for modifying or augmenting
the behavior of a function call, which is what is being done here.
 
> From a glance at other types of RPC frameworks it seems like they
> pretty strongly separate the object and its functions from the thing
> doing RPC on behalf of object.

...which is what we have now.

> Maybe what you are doing is similar (and hidden behind said
> decorator?). I wonder if instead of a function level decorator that u
> could basically wrap a given object (and its functions) with a proxy
> object and let said proxy object call via RPC. This avoids more
> decorator nastiness?

Nope, because a direct proxy is exactly what we're trying to avoid.
That's why the proposal says: "It does not attempt to track instances
that are in-flight or in use by other services." The code that uses
these objects depends on their format (keyed by a version), and since it
may not match that of the server that gave it the object, we need to be
more careful than just a function proxy.

> This seems similar to the xmlrpclib or pyro4 (in concept) which does
> similar automagic conversion.

These are, IMHO, orthogonal to what we're trying to accomplish here
and related mostly in that they show up in the first few hits in a
google search for "python rpc objects" :)

Thanks!

--Dan