From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44208) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKTiP-0003Ja-9a for qemu-devel@nongnu.org; Wed, 29 Jul 2015 11:56:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKTiL-0003SN-4R for qemu-devel@nongnu.org; Wed, 29 Jul 2015 11:56:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53739) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKTiK-0003Rz-TJ for qemu-devel@nongnu.org; Wed, 29 Jul 2015 11:56:17 -0400 References: <1435782155-31412-1-git-send-email-armbru@redhat.com> <1435782155-31412-46-git-send-email-armbru@redhat.com> <55B1B121.7040404@redhat.com> <87mvygs673.fsf@blackfin.pond.sub.org> <55B7D3E7.4090600@redhat.com> <87d1zbianl.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <55B8F79A.7020006@redhat.com> Date: Wed, 29 Jul 2015 09:56:10 -0600 MIME-Version: 1.0 In-Reply-To: <87d1zbianl.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="S3NDIA63rtHKTqiCtEq1h14d6m3K6UhX4" Subject: Re: [Qemu-devel] [PATCH RFC v2 45/47] qapi: New QMP command query-schema for QMP schema introspection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, berto@igalia.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S3NDIA63rtHKTqiCtEq1h14d6m3K6UhX4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/29/2015 03:19 AM, Markus Armbruster wrote: >>> Longest line is a bit over 4KiB for me. >>> >> >> If we break up string literals, at least use some indentation to make = it >> obvious that multiple lines merge to a single array entry. For example= >> (after patch 47): >> >> ... >> "{ 'name': ':abr', 'meta-type': 'object', " >> "'members': [ " >> "{ 'name': 'device', 'type': ':acg', 'default': null }, " >> "{ 'name': 'node-name', 'type': ':acg', 'default': null }, " >> "{ 'name': 'snapshot-file', 'type': ':acg' }, " >> "{ 'name': 'snapshot-node-name', 'type': ':acg', 'default': nu= ll >> }, " >> "{ 'name': 'format', 'type': ':acg', 'default': null }, " >> "{ 'name': 'mode', 'type': ':afo', 'default': null } ] }, " >> "{ 'name': ... " >=20 > Unconventional indentation, but if it helps the reader... I'm not a stickler about the particular spacing I used, so much as demonstrating an idea. Pick any indentation you like; I was just demonstrating that some well-chosen line breaks, coupled with visual clues on what belongs together, can help in reading the string literal in the generated file. In fact, doesn't python have a way to pretty-print JSON, and then post-process the pretty-printed string to add C \" escaping? >> And if we don't want sorting, documenting= >> that data is NOT guaranteed to be position-dependent, in spite of bein= g >> in a JSON array, is a nice touch. >=20 > What do you mean by "position-dependent"? If qemu 2.5 has { 'struct':'Foo', 'data': { 'b': 'int', 'c': 'int' } }, then qemu 2.6 adds '*a': 'int' to the end of that list, then either we guarantee sorting (if you read the members and see 'b' first, then you know 'a' was not added) or we don't (you must read the entire list to see if 'a' has been added; and you cannot assume that 'a' will be last even if it was listed last in the .json file of 2.6); the position in the .json file need not determine the position in the introspection outpu= t. >> But, as with enum sorting, actually documenting our choice will help >> cement the expectations of clients on what they have to do when learni= ng >> if a parameter was added. >=20 > We may want to adopt a consistent rule on sorting stuff. To be consistent, the rule would be that either everything is sorted, or nothing is; and if we choose nothing to be sorted, we are unlikely to ever want to add sorting in the future. >>> I could shoehorn both views into a single visitor function, by passin= g >>> both views, .base + .local_members, and .members. All implementation= s >>> will use only one of the views, but it's not immediately obvious whic= h >>> one. So I chose to have two visitor functions. Matter of taste. >> >> I can live with it (documentation that sub-classes should override at >> most only one of the two visitors might help the cause, though). >=20 > Actually, overriding both would be just fine. We just haven't had a us= e > for that. I guess it's hard to predict why a visitor would want to have both callbacks called for every object, so we can't outright state that it is useless. The whole point of a visitor interface is to provide flexibility in designing a visitor later down the road :) --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --S3NDIA63rtHKTqiCtEq1h14d6m3K6UhX4 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVuPeaAAoJEKeha0olJ0Nq9MYH/032ANbeP+L781lNpV6kINl6 DdpyEkuiyXtMZMMjdrRIhyFVSE5KQb4OPT8PKWJh4gWZVYKvQaWcWFapJ3UFvxg6 mR0eEw0wtTANAeFV6hnnybm+Q1ebJpcLKUA9+n7MAlMG1RvuFGWO8Yp/sh4oFpiw XiejmFaXHQA5uIO3gZCSnVPgB+ytT5Ol1eYqiaayk7YQKAwm2QX/Q9jiaSCZ4gaa xieAhV2znwoiaJ2kX6P7ocd9/v7qFa6azYvmuVgiMKJBoSHxy9mzncu9Iqh6nuvF thedAx0O8qp5hd3jmWBPykz/0GRYQysi5c+tlC7dyNCWreIk4r5S2ALNSVEXmnk= =QaCm -----END PGP SIGNATURE----- --S3NDIA63rtHKTqiCtEq1h14d6m3K6UhX4--