From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40425 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ODasI-0003sC-Fh for qemu-devel@nongnu.org; Sun, 16 May 2010 06:15:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ODasG-0004nh-A1 for qemu-devel@nongnu.org; Sun, 16 May 2010 06:15:10 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:43940) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ODasF-0004nb-VB for qemu-devel@nongnu.org; Sun, 16 May 2010 06:15:08 -0400 Message-ID: <4BEFC5A4.2010001@web.de> Date: Sun, 16 May 2010 12:15:00 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <6e14cbfe3764b46d9bd6d2db61d41fd9c85dd54e.1273843151.git.jan.kiszka@siemens.com> <4BED9358.1000106@codemonkey.ws> <4BEE5F0F.2060600@web.de> <4BEE6035.2070906@redhat.com> <4BEE6254.6060701@web.de> <4BEEDA7E.7060805@redhat.com> <4BEFBCE8.1030704@redhat.com> <4BEFBFE9.7010005@redhat.com> In-Reply-To: <4BEFBFE9.7010005@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA3938981B475C4F05AAC2DBF" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH 3/8] Add QBuffer List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Liguori , Juan Quintela , Markus Armbruster , qemu-devel@nongnu.org, Luiz Capitulino , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA3938981B475C4F05AAC2DBF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 sect= ion >>>> 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? >=20 > 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 anoth= er. 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__'] =3D=3D 'buffer': return base64.b64decode(dct['data']) else: return return dct and line =3D json.loads(self.sockfile.readline(), object_hook=3Dself.__json_obj_hook) i.e. parse the QMP stream into a proper representation without known QMP at all. >=20 > 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. >=20 Not everywhere, just into those nodes that aren't expressible with native JSON types. Jan --------------enigA3938981B475C4F05AAC2DBF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkvvxakACgkQitSsb3rl5xT6IwCfXbtQI/K3XH7cDcGF2RxxIcZK LGUAoLAL3voEJLteIfmThfTNO2RegIFy =BNZt -----END PGP SIGNATURE----- --------------enigA3938981B475C4F05AAC2DBF--