From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MJSPH-0003i1-JE
	for qemu-devel@nongnu.org; Wed, 24 Jun 2009 09:20:55 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MJSPC-0003fo-Iv
	for qemu-devel@nongnu.org; Wed, 24 Jun 2009 09:20:54 -0400
Received: from [199.232.76.173] (port=33752 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MJSPC-0003fj-97
	for qemu-devel@nongnu.org; Wed, 24 Jun 2009 09:20:50 -0400
Received: from mx2.redhat.com ([66.187.237.31]:41231)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1MJSPB-0005hZ-Ps
	for qemu-devel@nongnu.org; Wed, 24 Jun 2009 09:20:50 -0400
Message-ID: <4A42286C.2020608@redhat.com>
Date: Wed, 24 Jun 2009 16:21:48 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file
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>
	<20090624130213.GF28256@redhat.com>
In-Reply-To: <20090624130213.GF28256@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>, Vincent Hanquez <tab@snarc.org>

On 06/24/2009 04:02 PM, Daniel P. Berrange wrote:
>
> 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 don't understand the difference.  Every controllable feature should be 
exposed by the monitor, and nothing else.  In both cases.

-- 
error compiling committee.c: too many arguments to function