From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UueMj-0001L5-2i for qemu-devel@nongnu.org; Thu, 04 Jul 2013 03:54:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UueMh-00059P-Gz for qemu-devel@nongnu.org; Thu, 04 Jul 2013 03:54:08 -0400 Received: from mail-we0-x22e.google.com ([2a00:1450:400c:c03::22e]:43430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UueMh-00059G-99 for qemu-devel@nongnu.org; Thu, 04 Jul 2013 03:54:07 -0400 Received: by mail-we0-f174.google.com with SMTP id q58so848106wes.33 for ; Thu, 04 Jul 2013 00:54:06 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51D52A11.8070409@redhat.com> Date: Thu, 04 Jul 2013 09:53:53 +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> <51D4391B.20106@redhat.com> <871u7fk4qa.fsf@codemonkey.ws> In-Reply-To: <871u7fk4qa.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 , qemu-devel@nongnu.org, armbru@redhat.com Il 03/07/2013 18:06, Anthony Liguori ha scritto: > 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. If we generated a Python or C API based on the schema, should the client care (or know) that QMP is JSON? >> 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. What about returned types? I'm not sure we've never added non-optional arguments, even though in principle it was not the right thing to do. >>> 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. Not necessarily, a type that is currently used in two places can be split in two different types, with different optional fields. I understand though that command_dict['data']['parameter'] is either always true or always false, because new parameters are always added as optional. Still, for something that targets a new-enough QEMU only, there is no need to know if the parameter has always been there, or was added as optional. > What are we really optimizing here for? I think we should optimize for the clients, not for ourselves. Paolo > 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 >>> > > >