From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J289c-0001kI-Lu for qemu-devel@nongnu.org; Tue, 11 Dec 2007 11:40:20 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J289Z-0001eC-Pk for qemu-devel@nongnu.org; Tue, 11 Dec 2007 11:40:19 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J289Z-0001dQ-HO for qemu-devel@nongnu.org; Tue, 11 Dec 2007 11:40:17 -0500 Received: from il.qumranet.com ([82.166.9.18]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J289Y-0002LH-S9 for qemu-devel@nongnu.org; Tue, 11 Dec 2007 11:40:17 -0500 Message-ID: <475EBD6E.4030209@qumranet.com> Date: Tue, 11 Dec 2007 18:40:14 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API References: <475EAE8F.4020209@codemonkey.ws> <475EB3FC.1010106@qumranet.com> <200712111618.58860.paul@codesourcery.com> In-Reply-To: <200712111618.58860.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org Paul Brook wrote: >>> Why can't we make the monitor interface a "formal" interface? >>> >> Because then fixing a type or extending the interface becomes a pain. >> >> It's also much more difficult to specify a text-base interface >> completey, compared to a C api (where sometimes all you need is the >> header and a few comments). >> > > I disagree. > > It's entirely possible to fully specify a text protocol, Of course it's possible; it has been done many times. I've printed out several pounds of http myself. It isn't easy, especially starting from something intended for human consumption. > and it's just as easy > to extend it in a backwards compatible way. It's hard to correct a typo in a backwards compatible way. I think it's best to separate the human readable protocol from the machine readable protocol. > A C API is about the most fixed > interface you could possible use. But it's easy to add things without breaking it. > A C API also requires that both sides of > the interface be part of the same process on the same machine. My plan was for the library to connect to the managing process using a protocol of its choice. But I'm withdrawing it in favor of Dan Berrange's idea of having a client library. If you prefer a dedicated machine readable protocol, then I think that's workable too. But it has to be decoupled from the human readable monitor protocol. -- error compiling committee.c: too many arguments to function