From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJXj1-0006fm-CA for qemu-devel@nongnu.org; Wed, 24 Jun 2009 15:01:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJXiw-0006cU-8l for qemu-devel@nongnu.org; Wed, 24 Jun 2009 15:01:38 -0400 Received: from [199.232.76.173] (port=41009 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJXiv-0006cK-TF for qemu-devel@nongnu.org; Wed, 24 Jun 2009 15:01:33 -0400 Received: from mx20.gnu.org ([199.232.41.8]:26156) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJXiv-0001x3-6q for qemu-devel@nongnu.org; Wed, 24 Jun 2009 15:01:33 -0400 Received: from mail2.shareable.org ([80.68.89.115]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJXiu-0005Hi-F3 for qemu-devel@nongnu.org; Wed, 24 Jun 2009 15:01:32 -0400 Date: Wed, 24 Jun 2009 20:01:29 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090624190129.GQ14121@shareable.org> References: <4A40FE31.2010007@us.ibm.com> <4A40FFB0.2070905@redhat.com> <4A411FC5.7050701@us.ibm.com> <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> <20090624145646.GE31487@arachsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090624145646.GE31487@arachsys.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chris Webb Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , Avi Kivity , Vincent Hanquez Chris Webb wrote: > Anthony Liguori writes: > > > There are two questions to resolve. The first is whether we should > > continue with the current direction (line-based protocol) or whether we > > should switch to an RPC. The second question is which RPC we should use. > > > > I'm not at all convinced that we should switch to an RPC mechanism in > > the first place. Perhaps someone could summarize the advantages of > > doing this because right now, I don't see many. > > > > With respect to RPC choice, if we did go that route, I'd be very > > concerned about using jsonrpc verses a more well established rpc. I > > would honestly prefer xml-rpc over jsonrpc. > > We are an example of a end user of qemu (or more specifically qemu-kvm) that > doesn't go via a management layer like libvirt. Our management shell scripts > directly control the virtual machines using the current line-oriented 'human > friendly' monitor. This is a bit of a pain, but not too bad in practice. I do the same. I even have a QEMU-monitor-multiplexor script, which accepts multiple monitor connections and issues the commands over the real monitor. So that I can have one script managing (basically insert/remove disk images, trigger reboots etc.), while still having monitor accesss from the command line for those special extras. > A more regular and well defined line-based protocol would be a big plus for > us, whereas something like jsonrpc or xml-rpc would be a complete disaster > to call from the shell---less useful than the current human oriented monitor > rather than more so. It's fine as long as there's a good shell-friendly utility. Unfortunately my experience of using D-Bus through it's shell utility was not positive. You need the utility to do more than just pass the whole request and response back and forth. It needs to combine and extract fields in compound structures, and escape/unescape when you need that. -- Jamie