From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJaJf-0000q6-2i for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:47:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJaJZ-0000jb-LV for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:47:37 -0400 Received: from [199.232.76.173] (port=34393 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJaJZ-0000jY-F2 for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:47:33 -0400 Received: from mail2.shareable.org ([80.68.89.115]:54769) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJaJY-0007Yf-Si for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:47:33 -0400 Date: Wed, 24 Jun 2009 22:47:30 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090624214730.GE14121@shareable.org> References: <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> <5b31733c0906241429n5535794co4c2b730b8b825ee8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5b31733c0906241429n5535794co4c2b730b8b825ee8@mail.gmail.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Filip Navara Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , Avi Kivity , Vincent Hanquez Filip Navara wrote: > > 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. I generally agree, and to be honest the most useful API for scripts is probably a "qemu-control [OPTIONS] CMD [ARGS...]" _program_ which they can run, along the same lines as apachectl for Apache, smbcontrol for Samba, ntpdc for NTPd, etc. Such a program can be third party or not, once the monitor behaviour is reliable for a program to use. -- Jamie