Avi Kivity wrote: > On 05/16/2010 12:37 PM, Paolo Bonzini wrote: >> On 05/15/2010 07:31 PM, Avi Kivity wrote: >>> On 05/15/2010 11:59 AM, Jan Kiszka wrote: >>>> >>>>> Is this __class__ stuff documented anywhere? >>>>> >>>> Not yet. Also, we should clarify the proposed private extension section >>>> that only "__some_key" is reserved for downstream, not >>>> '__some_other_key__' (i.e. downstream names must not end with '__'). >>>> >>> >>> Why use such weird names at all? What's wrong with 'class'? >> >> That it conflicts with e.g. PCI classes? > > Won't the context tell it apart? When you expect a pci function, > 'class': 'video' means one thing, when you read a buffer it means another.
The point is to make this notation context-independent so that you can do
def __json_obj_hook(self, dct):
if '__class__' in dct:
if dct['__class__'] == 'buffer':
return base64.b64decode(dct['data'])
else:
return
return dct
and
line = json.loads(self.sockfile.readline(),
object_hook=self.__json_obj_hook)
i.e. parse the QMP stream into a proper representation without known QMP
at all.
>
> The only reason to use a special name is if it's a protocol level
> feature that can happen in all contexts. But in that case we're better
> off with a schema, we don't want to push class descriptors everywhere.
>
Not everywhere, just into those nodes that aren't expressible with
native JSON types.
Jan
signature.asc
Description: OpenPGP digital signature
