From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47647 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PpL4K-0000B0-Pn for qemu-devel@nongnu.org; Tue, 15 Feb 2011 08:35:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PpL4J-0003Qu-FW for qemu-devel@nongnu.org; Tue, 15 Feb 2011 08:35:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:9139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PpL4J-0003Qd-70 for qemu-devel@nongnu.org; Tue, 15 Feb 2011 08:35:51 -0500 Date: Tue, 15 Feb 2011 11:35:43 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [RFC] qapi: events in QMP Message-ID: <20110215113543.7cd05677@doriath> In-Reply-To: <4D598D5F.6050101@codemonkey.ws> 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> <4D598D5F.6050101@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Markus Armbruster , qemu-devel On Mon, 14 Feb 2011 14:15:27 -0600 Anthony Liguori wrote: > 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 Maybe. Still, having to add a new command because we wanted to make a simple extension seems a bit overkill to me. I'm not sure how common this is going to be, however when we discussed QMP originally there were a lot on emphasis on this kind of feature. What makes it pretty hard to work on this project is that we are always changing our mind in a number of details. > 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. Yes, but I still do not see how easier it's going to be for a client writer if s/he has to choose among four commands that do the same thing. Please, note that I do see the internal benefits, as always, the disagreement is about the wire protocol. > > 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. Ok. > > The QMP conversion is almost done, I'll be able to post patches very soon. > > Regards, > > Anthony Liguori >