|
From: | Avi Kivity |
Subject: | [Qemu-devel] Re: [PATCH 3/8] Add QBuffer |
Date: | Sun, 16 May 2010 13:49:34 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 |
On 05/16/2010 01:16 PM, Paolo Bonzini wrote:
On 05/16/2010 11:50 AM, 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:Not yet. Also, we should clarify the proposed private extension sectionIs this __class__ stuff documented anywhere?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?Yes, of course, it you need to know the schema. If you don't know the schema you don't know the context.This QBuffer thing is something that a client QMP library could create automatically. Keys in a separate namespace (like '__class__') have the advantage of being easily picked up automatically by a wrapper of the JSON parser; if you used simply 'class' such as layer would need to know a schema, or it wouldn't know that "context".
Makes sense. So this is a protocol feature and needs to be documented as such.
(BTW I'd prefer something like '__encoding__'; the word "class" suggests much more than what it is in reality).
Agreed. -- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |