From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MLW2O-0005O3-Sk for qemu-devel@nongnu.org; Tue, 30 Jun 2009 01:37:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MLW2J-0005LX-Re for qemu-devel@nongnu.org; Tue, 30 Jun 2009 01:37:47 -0400 Received: from [199.232.76.173] (port=37997 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MLW2J-0005LS-Ld for qemu-devel@nongnu.org; Tue, 30 Jun 2009 01:37:43 -0400 Received: from mx2.redhat.com ([66.187.237.31]:45847) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MLW2J-0008Np-7n for qemu-devel@nongnu.org; Tue, 30 Jun 2009 01:37:43 -0400 Message-ID: <4A49A482.30908@redhat.com> Date: Tue, 30 Jun 2009 08:37:06 +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> <4A47A9B4.4050600@redhat.com> <4A480E0F.6030000@codemonkey.ws> <4A485971.1010000@redhat.com> <4A4922AC.4030707@codemonkey.ws> In-Reply-To: <4A4922AC.4030707@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/29/2009 11:23 PM, Anthony Liguori wrote: > Avi Kivity wrote: >>> I don't mind if this ends up looking like JSON, but I don't want to >>> have to enforce that it's remains JSON compatible in the long term. >>> We should have our own grammar that we can version and that people >>> can use as the basis of a client. >> >> That really reduces the attractiveness of the whole thing. Writing >> parsers and emitters should be an optional part of writing a qemu >> control program, not a required part. > I really disagree Writing parsers and emitters should be a required part of writing a qemu control program? > > Whatever we do for QMP, it will not be enabled for 0.11 so we have 6 > months to get it right. In the interest of moving forward and writing > patches instead of emails, here's what I'm thinking: > > 1) Update the QMP patches to support return values for monitor commands > 2) Update patches to support structured command output > 3) Update the patches to support higher level data types (like lists > and dictionaries) > 4) For whatever the emission format is, provide a regular grammar to > parse that output > > I will commit a patch series that meets these goals. We have six months so you'll commit some unreviewed patches now? This is deeply dissatisfying. > Given a regular grammar, it's extremely easy to convert to outputting > JSON, XML, or whatever. We can keep arguing about whether JSON is the > right format long term. However, I don't want the useful work of > conversing monitor commands to satisify 1-3 to be held up by arguments > about the emission format which is largely unrelated to the command > conversions. We can certainly get consensus on some things earlier. I don't see the need to commit without review though. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.