Re: [Qemu-devel] Re: [RFC] qapi: events in QMP

[Luiz Capitulino <lcapitulino@redhat.com>]

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