[openstack-dev] [Oslo] jsonutils support for datetimes

Flavio Percoco flavio at redhat.com
Tue Jun 4 07:17:49 UTC 2013


On 03/06/13 12:56 -0400, Russell Bryant wrote:
>On 06/03/2013 12:41 PM, Flavio Percoco wrote:
>> 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.

Cool. We can certainly benefit from this. When will this happen? It
seems to me that it won't happen 'til the Ith release - I mean, the
migration to oslo - and that's an issue for us. Also, it should be
less tight to RPC semantics.

I guess we could have a simpler workaround for this like the one in
Nova that will allow us to wait for the migration to happen.

>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.
>

I partially agree with this. I do like the object oriented
deserialization but I also think we should have support for more
common types. I don't like the idea of having to define a "model"
everytime I need to serialize / deserialize datetimes.

IMO, one of the things that is wrong in current approach is the fact
that to_primitive is always used, instead, I'd let the implementation
explicitly specify the "default" keyword and build a chain of hooks
that should be called during serialization / deserialization based on
their needs.

FWIW, I think considering to_primitive deprecated is wrong. We need
some basic serialization / deserialization support. What I would do
is keep to_primitive simple - or make it so - and let complex stuff
happen in the unified-object-model.

Cheers,
FF

-- 
@flaper87
Flavio Percoco



More information about the OpenStack-dev mailing list