Open Stack

Thanks for the details :-)

On 5/6/13 5:20 PM, "Dan Smith" <dms at danplanet.com> wrote:

>> 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
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev