From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuMaK-0007PV-Hg for qemu-devel@nongnu.org; Wed, 03 Jul 2013 08:55:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UuMaI-0005oo-B7 for qemu-devel@nongnu.org; Wed, 03 Jul 2013 08:55:00 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:49661) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UuMaI-0005oW-3h for qemu-devel@nongnu.org; Wed, 03 Jul 2013 08:54:58 -0400 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 3 Jul 2013 13:54:57 +0100 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 3E32E38C804A for ; Wed, 3 Jul 2013 08:54:53 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r63CsrOa162936 for ; Wed, 3 Jul 2013 08:54:54 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r63CsrwB023968 for ; Wed, 3 Jul 2013 09:54:53 -0300 From: Anthony Liguori In-Reply-To: <51D3BC3A.4030803@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> Date: Wed, 03 Jul 2013 07:54:47 -0500 Message-ID: <87wqp7g5wo.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: lcapitulino@redhat.com, qiaonuohan@cn.fujitsu.com, Amos Kong , armbru@redhat.com, qemu-devel@nongnu.org Paolo Bonzini writes: > Il 02/07/2013 22:58, Anthony Liguori ha scritto: >> > > We consume the schema in QEMU. No reason for us to consume it in a >> > > different format than libvirt. >> > >> > One reason could be that qapi-schema.json, as written, lacks a schema >> > that can be expressed itself using QAPI. >> >> Yup, but how much does that matter in practice? > > It matters little because we do not provide a library of QAPI > parsers/visitors, so clients have to invent their own anyway. > > But if we did, clients would be completely oblivious of the fact that > QMP is based on JSON. Sending qapi-schema.json down the wire as a JSON > string would break the abstraction that we provide to the clients. > >> At any rate, if we wanted to solve this problem--a self-describing >> schema--we should do it in qapi-schema.json too. > > I disagree. I also disagree that qapi-schema.json, as written, is a > format designed for machine consumption. > > 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. 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. The only reason we don't use json.loads() is because we want to provide stable ordering for generated command line arguments and struct members. We can't get that guarantee with the json module. But this doesn't matter for a client. QMP doesn't have a notion of argument ordering. > 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 To answer: A) Is 'type' valid? - bool('type' in type_dict) B) Does 'type' have optional parameter 'foo': - bool('*foo' in type_dict['data']) C) Does 'enum' have 'value' - bool('value' in enum_dict['data']) D) Does 'command' have 'parameter' - bool('parameter' in command_dict['data']) Now we could certainly return dictionaries instead of a list but that's a trivial post-processing step. > 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. That's the problem I have here. I don't see why we can't have both a human readable and machine readable syntax. Furthermore, qapi.py is an existence proof that we do :-) Regards, Anthony Liguori > > Paolo