From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35310 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pp4r2-00056q-Js for qemu-devel@nongnu.org; Mon, 14 Feb 2011 15:17:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pp4r0-0001vB-A9 for qemu-devel@nongnu.org; Mon, 14 Feb 2011 15:17:04 -0500 Received: from mail-qw0-f45.google.com ([209.85.216.45]:37044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pp4r0-0001uv-5t for qemu-devel@nongnu.org; Mon, 14 Feb 2011 15:17:02 -0500 Received: by qwk4 with SMTP id 4so3599586qwk.4 for ; Mon, 14 Feb 2011 12:17:01 -0800 (PST) Message-ID: <4D598D5F.6050101@codemonkey.ws> Date: Mon, 14 Feb 2011 14:15:27 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC] qapi: events in QMP References: <4D581E04.1020901@codemonkey.ws> <4D58FADB.3010005@redhat.com> <4D591A01.4030105@codemonkey.ws> <4D5920ED.6020104@redhat.com> <20110214104517.32b77291@doriath> <4D593E8F.7050306@codemonkey.ws> <20110214163443.57ad8a37@doriath> <4D5983B3.5010902@codemonkey.ws> <20110214175800.060d4204@doriath> In-Reply-To: <20110214175800.060d4204@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Kevin Wolf , Markus Armbruster , qemu-devel On 02/14/2011 01:58 PM, Luiz Capitulino wrote: > No, of course not, our plan has always been to do this via an schema, > the only reason we don't do this today is lack of time/help. > > Understood--I'm here to help now :-) >> We need to expose the schema, I'm not saying we shouldn't. But we don't >> today. >> >> You're arguing that we should extend commands by adding new parameters. >> > Commands and events, you haven't commented on events yet and that seems > a bit worse than commands. > Events are just commands that never return a value and are posted. IOW: client -> server message == command server -> client message == event However, we limit events to have no return value and semantically, when an event is invoked, the message is only posted (we're not guaranteed that the client has seen it). The reason for the lack of symmetry is to simplify the programming model. If we had to wait for an event to be ack'd and receive a return value, it would involve a lot of ugly callback registrations. But beyond those few limitations, events and commands should be treated exactly the same IMHO. > I disagree. Let's say we have added three new arguments to the command foo, > and now we have foo1, foo2 and foo3. I'm a quite old distro and only > have foo, which command should I backport? All of them? Only the latest? > > I can't see how easier this is. Backporting APIs will almost always suck. > 1) if we have to add three arguments to a command, we've failed in our API design after an initial release 2) it depends on what level of functionality the distro needs. The more complicated we make the API, the harder it will be to write clients against it. If we have four ways to do the same thing (even if that's via one command or four separate ones), writing a client is going to suck no matter what. > For C, yes. But one of the main goals of a high level protocol is to be > language independent, isn't it? > Yes, which means first-class support for a variety of languages with C being a very important one. >>> Look, although I did _not_ check any code yet, your description of the QAPI >>> looks really exciting. I'm not against it, what bothers me though is this >>> number of small limitations we're imposing to the wire protocol. >>> >>> Why don't we make libqmp internal only? This way we're free to change it >>> whatever we want. >>> >>> >> libqmp is a test of how easy it is to use QMP from an external >> application. If we can't keep libqmp stable, then that means tools like >> libvirt will always have a hard time using QMP. >> >> Proper C support is important. We cannot make it impossible to write a >> useful C client API. >> > I wouldn't say it's impossible, but anyway, the important point here is > that we disagree about the side effects QAPI is going to introduce in QMP, > I don't know how to solve this, maybe we can discuss this upstream, but I'm > not sure the situation will change much. > > Should we vote? :) > Let's wait until I actually post patches... My purpose of this thread was to get some feedback on using signal/slots as an abstraction in QEMU. The QMP conversion is almost done, I'll be able to post patches very soon. Regards, Anthony Liguori