From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJS7q-0004ci-Ad for qemu-devel@nongnu.org; Wed, 24 Jun 2009 09:02:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJS7l-0004Zm-9i for qemu-devel@nongnu.org; Wed, 24 Jun 2009 09:02:53 -0400 Received: from [199.232.76.173] (port=38208 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJS7l-0004ZX-24 for qemu-devel@nongnu.org; Wed, 24 Jun 2009 09:02:49 -0400 Received: from mx1.redhat.com ([66.187.233.31]:55713) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJS7k-0001Gx-DS for qemu-devel@nongnu.org; Wed, 24 Jun 2009 09:02:48 -0400 Date: Wed, 24 Jun 2009 14:02:14 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090624130213.GF28256@redhat.com> References: <4A40FD1A.1040303@redhat.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A42200C.6060600@codemonkey.ws> Reply-To: "Daniel P. Berrange" 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 , Vincent Hanquez On Wed, Jun 24, 2009 at 07:46:04AM -0500, Anthony Liguori wrote: > Vincent Hanquez wrote: > >On Tue, Jun 23, 2009 at 05:50:24PM -0500, Anthony Liguori wrote: > > > >>>this one is mentioned on the website and has been changed recently (may > >>>2009): > >>> > >>>http://fara.cs.uni-potsdam.de/~jsg/json_parser/ > >>> > >>> > >>That's not a jsonrpc library, that's just a json parser. > >> > > > >but this is completly trivial at this point. jsonrpc is a json message put > >in a > >certain way. > > > >now providing there was a maintained library out there, would you use it ? > >or do you have more concerns that were unanswered ? > > 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. It really depends what you consider the purpose of the monitor to be. If the monitor is the "API" application developers use for management, then a full blown RPC mechaism makes sense. If the monitor is an internal control mechanism, to enable the building mgmt tools, then RPC is overkill. I consider QEMU's monitor to be the latter, and interface for a single application to use (and developer debugging). If we try to turn the monitor into the general end-app developer mgmt interface, then you open the floodgates to vastly more functionality being pushed into the QEMU codebase. I don't think we want that, QEMU should be lean & mean, and if you want fancy RPC systems then do it in a tool layered above, be it libvirt, XenD, a CIM agent, or something else. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|