From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuPa7-0003ea-4Y for qemu-devel@nongnu.org; Wed, 03 Jul 2013 12:07:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UuPa2-0004IG-31 for qemu-devel@nongnu.org; Wed, 03 Jul 2013 12:06:59 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:60045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuPa1-0004IA-VI for qemu-devel@nongnu.org; Wed, 03 Jul 2013 12:06:54 -0400 Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 3 Jul 2013 12:06:53 -0400 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 2E65EC90068 for ; Wed, 3 Jul 2013 12:06:50 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r63G6p4d304074 for ; Wed, 3 Jul 2013 12:06:51 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r63G6olo000668 for ; Wed, 3 Jul 2013 12:06:50 -0400 From: Anthony Liguori In-Reply-To: <51D4391B.20106@redhat.com> References: <1371644677-11041-1-git-send-email-akong@redhat.com> <878v1pqak4.fsf@codemonkey.ws> <51D2F1B3.1080903@redhat.com> <20130702153945.GZ2524@redhat.com> <51D3035A.1060605@redhat.com> <877gh8j012.fsf@codemonkey.ws> <51D3314F.1070609@redhat.com> <87zju4wufh.fsf@codemonkey.ws> <51D3BC3A.4030803@redhat.com> <87wqp7g5wo.fsf@codemonkey.ws> <51D4391B.20106@redhat.com> Date: Wed, 03 Jul 2013 11:06:37 -0500 Message-ID: <871u7fk4qa.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH] full introspection support for QMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, qiaonuohan@cn.fujitsu.com, Amos Kong , armbru@redhat.com, lcapitulino@redhat.com Paolo Bonzini writes: > Il 03/07/2013 14:54, Anthony Liguori ha scritto: >>> So, qapi-schema.json has to be readable/writable _mostly_ by humans. >>> That it is valid JSON is little more than a curious accident, because >> >> I can assure you that it wasn't an accident. > > Sure, it is not. But when designing the right API for a QMP client, it > doesn't matter if it is or not. If QMP used ASN.1 or something like > that as the wire protocol, we would not use JSON just for the schema, > would we? JSON is a pretty good representation of Python data structures and the intention was for qapi-schema.json to be generated by another tool. But I understand the point you're trying to make. The thing is, QMP is JSON now so it's somewhat academic. >> The plan had been to start >> with what the output of a "human friendly" parser would be and then >> eventually introduce a more IDL like syntax. >> >> qapi-schema.json is valid JSON. It's a stream of objects. It's a >> stream of objects instead of a list to favor readability but that's >> really the only compromise. > > So far so good. > >>> overall the syntax greatly favors humans rather than computers. A >>> format designed for computers would have a schema such that no parsing >>> tasks (however small---I'm thinking of the "list of" and "optional" >>> syntaxes) would be left after parsing the JSON. >> >> Here is how I would handle "processing" qapi-schema.json: >> >> 1) Put all types, unions, and enums in their own dictionary >> 2) Put commands in a dictionary > > Agreed. > >> To answer: >> >> A) Is 'type' valid? >> - bool('type' in type_dict) >> >> B) Does 'type' have optional parameter 'foo': >> - bool('*foo' in type_dict['data']) > > Does 'type' have argument 'foo': > > bool('foo' in type_dict['data']) or > bool('*foo' in type_dict['data']) > > (as a QMP client I want to send the argument, I don't care if it is > optional or not) and here the abstraction is already falling, IMHO. It > should be one of these: Whether 'type' is in 'foo' is a static property. We would never add non-optional arguments to a function so the first part of the clause is a constant expression. > 'foo' in type_dict['data'].fields > 'foo' in type_dict['data']['fields'] Not sure I see why the extra layer of indirection is needed. > >> C) Does 'enum' have 'value' >> - bool('value' in enum_dict['data']) >> >> D) Does 'command' have 'parameter' >> - bool('parameter' in command_dict['data']) > > What is the type of 'parameter' in command: > > command_dict['data']['parameter'] or > command_dict['data']['*parameter'] That's a fair point. But again, this is a constant expression. Type values never change. What are we really optimizing here for? What are the things that someone is expected to use the schema to do in real life? Regards, Anthony Liguori > It should be something like these: > > command_dict['data'].arguments['parameter'].type > command_dict['data']['arguments']['parameter']['type'] > >>> The example that Eric sent is not something that I would find easy to >>> read/write. qapi-schema.json instead is more than acceptable. >> >> I don't think the example Eric sent is any easier to parse >> programmatically. > > It is, see the above examples. > >> That's the problem I have here. I don't see why we >> can't have both a human readable and machine readable syntax. > > It is machine readable, but that doesn't mean it constitutes a nice API. > > Paolo > >> Furthermore, qapi.py is an existence proof that we do :-) >> >> Regards, >> >> Anthony Liguori >> >>> >>> Paolo >>