From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJAMR-0005vq-AA for qemu-devel@nongnu.org; Tue, 23 Jun 2009 14:04:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJAMM-0005pQ-7O for qemu-devel@nongnu.org; Tue, 23 Jun 2009 14:04:46 -0400 Received: from [199.232.76.173] (port=58320 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJAML-0005oK-Ns for qemu-devel@nongnu.org; Tue, 23 Jun 2009 14:04:41 -0400 Received: from cerberus.snarc.org ([212.85.155.21]:47678) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJAMK-0002Ml-Ib for qemu-devel@nongnu.org; Tue, 23 Jun 2009 14:04:41 -0400 Date: Tue, 23 Jun 2009 18:59:55 +0100 From: Vincent Hanquez Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090623175955.GA3363@snarc.org> References: <20090623012811.53a62493@doriath> <20090623144521.GA614@snarc.org> <4A40FB11.8090100@redhat.com> <4A40FB26.2040702@us.ibm.com> <4A40FD1A.1040303@redhat.com> <4A40FE31.2010007@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A40FE31.2010007@us.ibm.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , Avi Kivity On Tue, Jun 23, 2009 at 11:09:21AM -0500, Anthony Liguori wrote: > Avi Kivity wrote: >>> I'd rather not do json. >>> >> >> Why not? > > Because it's too much complexity at this level in the stack. It's not. instead of replying the OK, ERROR .. you reply a JsonRPC OK|ERROR structure with the same string (quoted and utf-8) as the data payload. instead of parsing each command line with the text protocol thing, you'll get every parameter from a json array of string (can contain any characters compared to QMP so far). if you want you can make things generic at the marshalling level, by using string everywhere .. which is what QMP is doing. >>> As they stand, I think the current patch set is very close to being >>> mergable. I'd rather not go off on a new tangent. >> >> It fulfils all are requirements and more. There's a C implementation >> available. We can concentrate on the commands and ignore the plumbing. > > The same is true for XML-RPC, CIM, dbus, etc. RPC grow like weeds. In > 5 years, it will be shocking that qemu uses jsonrpc instead of the next > super-neat RPC protocol. > > If we did a real RPC mechanism, I'd want to stick with something > tried-and-true like XDR. But an RPC mechanism is not the monitor. If > we were going to do that, there's no point in morphing the monitor into > that. CIM, dbus are binary protocol. same apparently for XDR (which i've never used). only XMLRPC is fairly similar (but much more verbose and xml is ugly) Jsonrpc is just one "standard" marshalling protocol, that I think would fit quite well, but the point is using something already out there not something that looks like the evil cousin of the IRC protocol. Usually too, if the rpc has been correctly bolted on something, changing one to the other is usually trivial (for example xmlrpc to jsonrpc or the other way). So maybe in 5 years, people will push for a new protocol XYZ .. but that doesn't mean it's not going to happen to QMP too anyway... > What we're doing here is adding a computer-mode to the existing monitor. > This will be easy for current apps to consume and for us to transition > the code base to. It's a safe and incremental improvement. i don't see my "proposal", as going against this statement. you could bolt jsonrpc or xmlrpc or in an incremental fashion too. > I don't want to invent Xen-API here and go through that pain in QEMU. This is really *not* comparable to Xen-API. QEMU manage VM and only VM. Xen-API goes much further. -- Vincent