From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NVD9q-0001bi-L9
	for qemu-devel@nongnu.org; Wed, 13 Jan 2010 19:01:50 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NVD9n-0001St-1e
	for qemu-devel@nongnu.org; Wed, 13 Jan 2010 19:01:50 -0500
Received: from [199.232.76.173] (port=51674 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NVD9m-0001Se-QX
	for qemu-devel@nongnu.org; Wed, 13 Jan 2010 19:01:46 -0500
Received: from mail2.shareable.org ([80.68.89.115]:36977)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1NVD9m-00014y-98
	for qemu-devel@nongnu.org; Wed, 13 Jan 2010 19:01:46 -0500
Date: Thu, 14 Jan 2010 00:01:39 +0000
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] QMP forward compatibility support
Message-ID: <20100114000139.GB18418@shareable.org>
References: <20100111163422.0d86d2bb@doriath> <4B4B748B.6010008@codemonkey.ws>
	<20100111220436.14c662a5@doriath> <4B4BC138.1000500@codemonkey.ws>
	<20100112101102.396b15fb@doriath>
	<m3hbqqndyl.fsf@blackfin.pond.sub.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m3hbqqndyl.fsf@blackfin.pond.sub.org>
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: Markus Armbruster <armbru@redhat.com>
Cc: aliguori@us.ibm.com, dlaor@redhat.com, avi@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>

Markus Armbruster wrote:
> It should be optional if we want to support clients that don't want it.
> I don't think coping with it would be a terrible burden on clients, but
> neither is having to ask for it.  Personally, I'd make it optional.

It wouldn't be a terrible burden, but it'll be easier to write "quick
and dirty" synchronous clients if they know they don't have to
continuously consume output, to make sure the pipe doesn't fill up,
except immediately after they send a command they wait for the response.

So I'd make async responses optional too.

By quick and dirty, I am talking about one-liner Perl invocations in
shell scripts which control a qemu instance.  Something which is easy
with multi-monitor support :-)

-- Jamie