From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuOMk-0000T4-IY for qemu-devel@nongnu.org; Wed, 03 Jul 2013 10:49:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UuOJm-0003kx-2V for qemu-devel@nongnu.org; Wed, 03 Jul 2013 10:46:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuOJl-0003iL-Gh for qemu-devel@nongnu.org; Wed, 03 Jul 2013 10:46:01 -0400 Message-ID: <51D4391B.20106@redhat.com> Date: Wed, 03 Jul 2013 16:45:47 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <87wqp7g5wo.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] full introspection support for QMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: lcapitulino@redhat.com, qiaonuohan@cn.fujitsu.com, Amos Kong , armbru@redhat.com, qemu-devel@nongnu.org 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? > 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: 'foo' in type_dict['data'].fields 'foo' in type_dict['data']['fields'] > 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'] 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 >