From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJa2L-0002VL-Ls for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:29:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJa2H-0002Ss-S4 for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:29:45 -0400 Received: from [199.232.76.173] (port=54527 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJa2H-0002Sg-Ms for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:29:41 -0400 Received: from mail-ew0-f211.google.com ([209.85.219.211]:54109) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJa2H-00053k-7N for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:29:41 -0400 Received: by ewy7 with SMTP id 7so1519759ewy.34 for ; Wed, 24 Jun 2009 14:29:38 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20090624211358.GA14121@shareable.org> References: <4A412339.5000109@redhat.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> Date: Wed, 24 Jun 2009 23:29:38 +0200 Message-ID: <5b31733c0906241429n5535794co4c2b730b8b825ee8@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file From: Filip Navara Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , Avi Kivity , Vincent Hanquez On Wed, Jun 24, 2009 at 11:13 PM, Jamie Lokier wrote: > Filip Navara wrote: >> > QEMU's monitor is already much easier to use than that. >> >> For human? Definitely! For shell scripts? Yes. For libraries that need >> to parse the data reliably? No. > > Yes, it could do with a more well-defined formatting. > > Documented escaping of unusual characters in names would be a start :-) > >> > When a new monitor command is added, you can use it from scripts as >> > trivial one-liner text commands, assuming you already have a way to >> > connect to the monitor. >> >> Since when was calling from scripts added as requirement? Don't get me >> wrong, I would be happy to cover this use case as well. It's a diverse >> use case from the libvirt usage though, in my humble opinion. > > Aren't most QEMU management programs (other than libvirt) scripts? I don't feel competent to answer that. > Looks to me like "works with libvirt and other management programs" > implies that you can use it from scripts, because many management > programs are, in fact, scripts. If that was true then certainly a text/line-based protocol would make sense (possibly in addition to a simple RPC one, if desired). The thing I am worried about is that several corner cases are currently not defined in the proposed protocol and it introduces asynchronous events, which is actually harder to get right in shell scripts than the human protocol. > If the requirement is simply "works with libvirt", then closer > integration with libvirt would be better than trying to cleanly RPC > everything. =A0After all, libvirt already has it's own RPC layer for > everything connecting to it, and libvirt people want all QEMU > interaction to happen via libvirt anyway. =A0There's no point having > multiple different RPC layers carrying exactly the same commands in > different ways. > > -- Jamie > Best regards, Filip Navara