From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKyFt-00020S-TV for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:33:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKyFp-0001zm-AU for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:33:29 -0400 Received: from [199.232.76.173] (port=60802 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKyFp-0001zj-54 for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:33:25 -0400 Received: from mx2.redhat.com ([66.187.237.31]:57069) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKyFo-0007kp-M0 for qemu-devel@nongnu.org; Sun, 28 Jun 2009 13:33:25 -0400 Message-ID: <4A47A9B4.4050600@redhat.com> Date: Sun, 28 Jun 2009 20:34:44 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file References: <4A412339.5000109@redhat.com> <4A412659.1080803@us.ibm.com> <20090623220204.GA5612@snarc.org> <4A415C30.7030301@us.ibm.com> <20090624010108.GA6537@snarc.org> <4A42200C.6060600@codemonkey.ws> <5b31733c0906240857g546316e0pd92fee9afe6115fa@mail.gmail.com> <4A4252DD.70300@redhat.com> <20090624190539.GR14121@shareable.org> <5b31733c0906241224j50baa7e6lc80b8c79c5d6baa7@mail.gmail.com> <20090624211358.GA14121@shareable.org> <4A43768A.2090604@eu.citrix.com> <4A438FDD.5060206@redhat.com> <4A43935D.6000506@codemonkey.ws> <4A4395B8.4010401@redhat.com> <4A43BD5D.80307@codemonkey.ws> <4A43C264.6060803@redhat.com> <4A43D600.8060605@codemonkey.ws> <4A449113.8070907@redhat.com> <4A44CB74.1070808@codemonkey.ws> <4A44E2F3.8050804@codemonkey.ws> <4A476C60.1080609@redhat.com> <4A47A70B.7070806@codemonkey.ws> In-Reply-To: <4A47A70B.7070806@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "ehabkost@redhat.com" , Stefano Stabellini , "jan.kiszka@siemens.com" , "dlaor@redhat.com" , "qemu-devel@nongnu.org" , Luiz Capitulino , Filip Navara , Vincent Hanquez On 06/28/2009 08:23 PM, Anthony Liguori wrote: >> It's important to allow clients to use json emitters so they can >> construct a dict and throw it at qemu, similarly to parse qemu results. >> >>> arg_list: value arg_list? >>> >>> command: symbol arg_list? '\n' >> >> Better to use a dictionary for the argument list (more >> self-documenting, easier expansion). > > Verses a list? I'm not sure a dict fits the current QEMU model very > well. How would you propose fitting it into the current monitor > infrastructure? First, I would like to consider the protocol mostly from the point of view of clients, not qemu, and certainly not current qemu code. There is only one qemu, but many clients. Code problems can be solved tomorrow, but interface problems remain forever. Second, I think it fits quite nicely. Positional arguments are nasty when you have many of them, especially when some are optional. And we already support dictionaries: -drive file=blah,cache=none. We make a dictionary interface, and have both the command line parser and the monitor json thing implement it. (note: it would be nice to have this interface detect unused arguments so we can flag typos in keywords). >> Similarly, return a value that contains message type, id, and return >> value. > > I think command outputs are basically return values. What's nice > about the current QMP proposal is that we're basically returning tuples. Yes, I meant { 'type': 'respose', 'id': 'foo', 'return': value }. 'type' is the new =, and 'id' is the tag. If multiple return values are needed, value can be a list or dictionary. >> I think it's fine to drop jsonrpc as the standard (but retain its >> features) and just adopt json for encoding. > > Yeah, I think if we focus on defining a grammar and semantics, if it > happens to look like JSON, I don't really care. I just don't want to > adopt the baggage of json and particularly json-rpc. If 'looks like' == 'compatible with', I agree. -- error compiling committee.c: too many arguments to function