On Mon, 14 Feb 2011 14:15:27 -0600 Anthony Liguori <anth...@codemonkey.ws> 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 >
