Open Stack

On Tue, 2013-05-07 at 16:01 -0700, Dan Smith wrote:
> > 'args': {
> >     'arg1': {
> >         'oslo.object_name': 'nova.MyObject',
>
> That looks good to me.

Yep.


> > jsonutils.dumps() will automatically call jsonutils.to_primitive() on
> > anything that is not a primitive type.  We could add a check in there
> > to see if the object has a to_primitive() method and if so, call that.
> 
> Hmm, I'll have to look at this a bit. I had it hacked into RpcProxy,
> since we have easy access to the args, each of which we can check for
> object-ness and serialize as needed. I liked this because of the
> symmetry of putting the deserialization in RpcDispatcher. Just to be
> clear, you're suggesting keeping jsonutils.to_primitive() and making it
> stop recursing at an object with to_primitive() and call that instead?
>  
> > On the deserialize side, there's no hook really.  You could subclass
> > RpcDispatcher, override the dispatch() method and do it there, and
> > then let the base dispatch() do its thing after you do
> > deserialization magic.
> 
> Yeah, that was the plan. Would it be better to add "serialize_args()"
> and "deserialize_args()" to Proxy and Dispatcher so that it's all in
> one place and very clear?

If you look at my WIP re-design of the RPC API:

https://github.com/markmc/oslo-incubator/commit/1f2f7fab

you'll see that Proxy and Dispatcher basically become rpc.Client and
rpc.Server - users of those APIs only deal in Python method calls which
the rpc layer serialize to and from dicts which it passes down to the
messaging layer.

I guess you're wondering whether to have the messaging layer just deal
with dicts of primitives and require the rpc layer to serialize objects
to primitives, or do it all at the messaging layer.

I like the simplicity of messaging dealing with dicts of primitives. We
can re-use support the same object serialization method at the
notifications layer too. Can see the argument for just doing it all at
the messaging layer, though.

Cheers,
Mark.