Open Stack

On 06/03/2013 12:41 PM, Flavio Percoco wrote:
> On 03/06/13 11:28 -0400, Russell Bryant wrote:
>> On 06/03/2013 09:14 AM, Doug Hellmann wrote:
>>> You could also just include the _type and _value, leaving the
>>> interpretation of that value up to the receiver.
>>>
>>> At the summit there was a proposal in the nova track to support sending
>>> arbitrary objects over RPC transparently as part of the versioned object
>>> session [1]. I think the final proposal involved using a registry of
>>> types with serializers and deserializers. Datetimes could just be
>>> another type in that registry system.
>>
>> Yes, and I would encourage any and all projects affected by this to go
>> down a similar path.  This project is well under way.
>>
>>  https://blueprints.launchpad.net/nova/+spec/rpc-support-for-objects
>>
>>  https://blueprints.launchpad.net/nova/+spec/unified-object-model
>>
> 
> Interesting, I didn't know about unified-object-model.
> 
> As for glance, we need to have basic serialization for datetimes
> without supporting more complex objects and not based on current RPC
> code but HTTP communication. I gave a quick look at the code written
> for unified-object-model and it seems to be way too tight to Nova. Are
> you guys willing to make it more generic and contribute to oslo? Am I
> missing something? Dan?

We're proving it out in Nova.  It could certainly be more widely used.
Once it settles down, we can look at which additional parts to put in
oslo if others want to use it.

>> As for the current jsonutils code, I would just leave it how it is and
>> avoid making any format changes.  It's going to break backwards
>> compatibility for code that uses it right now.
> 
> I understand the concern but, if there's room for improvement, I bet
> we can find a good way to not break it. My concern is that this seems
> to be a common issue and supporting it shouldn't require a big
> re-factor, instead, it should be small - relative to the project - and
> straightforward,  IMHO.
> 
> As a gentle clarification, what I'm trying to add is support for json
> serialization / de-serialization of datetime objects. For more complex
> objects I'd definitely go down unified-object-model's way.

The only magic in jsonutils right now is serialization, no
de-serialization.  I think to_primitive() (the serialization part) is
already pretty evil.  Adding a deserialization equivalent is going to be
just as gross, IMO.  It's going to be another "recursively traverse the
entire thing looking for places to do magic".  Meh.

I would really rather see us all consider to_primitive() deprecated.  If
you need support for serializing non-primitive types, I think having
objects that understand how to serialize/deserialize themselves is the
way to go.

-- 
Russell Bryant