From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu2gO-00081S-4D for qemu-devel@nongnu.org; Tue, 02 Jul 2013 11:39:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uu2gL-0002nM-Vs for qemu-devel@nongnu.org; Tue, 02 Jul 2013 11:39:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41329) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uu2gL-0002n9-NE for qemu-devel@nongnu.org; Tue, 02 Jul 2013 11:39:53 -0400 Date: Tue, 2 Jul 2013 16:39:45 +0100 From: "Daniel P. Berrange" Message-ID: <20130702153945.GZ2524@redhat.com> References: <1371644677-11041-1-git-send-email-akong@redhat.com> <878v1pqak4.fsf@codemonkey.ws> <51D2F1B3.1080903@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51D2F1B3.1080903@redhat.com> Subject: Re: [Qemu-devel] [PATCH] full introspection support for QMP Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Anthony Liguori , qemu-devel@nongnu.org, armbru@redhat.com, lcapitulino@redhat.com, qiaonuohan@cn.fujitsu.com, pbonzini@redhat.com, Amos Kong On Tue, Jul 02, 2013 at 09:28:51AM -0600, Eric Blake wrote: > On 07/02/2013 08:51 AM, Anthony Liguori wrote: > > Amos Kong writes: > > > >> Introduces new monitor command to query QMP schema information, > >> the return data is a nested dict/list, it contains the useful > >> metadata. > >> > >> we can add events definations to qapi-schema.json, then it can > >> also be queried. > >> > >> Signed-off-by: Amos Kong > > > > Maybe I'm being too meta here, but why not just return qapi-schema.json > > as a string and call it as day? > > Because qapi-schema.json requires further parsing. For example, how is > a client supposed to know that '*foo':'int' means that there is an > argument named 'foo' but it is optional? The rule of thumb with QMP is > that if you have to post-process JSON output, then the JSON was not > designed correctly. Arguably that rule of thumb would apply equally to the QEMU build scripts which already parse qapi-schema.json. It could be possible to normalize qapi-schema.json somewhat to remove this 2-stage parsing if we went down this route. > > It's JSON already and since QMP is JSON, the client already has a JSON > > parser. Adding another level of complexity doesn't add much value IMHO. > > qapi-schema.json is not quite JSON, in that it has #comments that we'd > have to strip before we attempted a trick like this. I've also been the > one arguing that the additional complexity (an array of > {"name":"str","type":"str","optional":bool"}) is better for libvirt in > that the JSON is then well-suited for scanning (it is easier to scan > through an array where the key is a constant "name", and looking for the > value that we are interested in, than it is to scan through a dictionary > where the keys of the dictionary are the names we are interested in). > That is, the JSON in qapi-schema.json is a nice compact representation > that works for humans, but may be a bit TOO compact for handling via > machines. I'm finding it hard to clearly see what the 2 different proposed data formats look like against each other. Can someone give some examples, showing the data that would need to be parsed in each format, for a couple of examples. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|