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

[Anthony Liguori <anthony@codemonkey.ws>]

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