Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/10/2011 09:45 AM, Avi Kivity wrote:
>>
>>> btw2, I now nominate subscribe and unsubscribe as replacements for 
>>> get and put.
>>
>> Subscribe implies sub/pub in my mind and we're not publishing events 
>> so I don't think it fits the model.
>>
>> A pub/sub event model would be interesting to think through but 
>> without a global namespace and object model, I don't think we can 
>> make it fit well.
>
> I feel we're still not communicating.  What does 'get-*-event' mean?
>
> I think you're using some nomenclature that is unfamiliar to me.

No, I'm just defending something that I think fundamentally sucks.

I very purposefully am trying to avoid heavy protocol visible changes at 
this stage.  The only reason I added signal accessors is that the 
current event model is unusable from a C API.

I am in full agreement that the current signal model needs to be 
rethought and should be changed at the protocol level.  I just don't 
want to do that right now because there are a ton of internal 
improvements that can be made by without doing that.

The signal accessors are ugly but they're just a handful of commands 
that can be deprecated over time.  We should revisit events but we 
should take the time to design it and plan for a protocol addition for 0.16.

>
>> That's why I'm using signal/slots.  It's much more conducive to a 
>> procedural model.
>
> I still don't follow.  We have a connection, over which we ask the 
> other side to let us know when something happens, then that other side 
> lets us know when it happens, then we ask it to stop, then it stops.  
> There are no signals or slots anywhere.  If there are in the code, 
> let's not mix it up with the protocol.

Dropping my legacy baggage, here's what I'd like to see us do from a 
protocol perspective.  I'd like to first introduce class hinting and 
switch all of the string handles that we use today to class handles.   So:

{ execute: query-block }
{ return: [ { __jsonclass__: 'BlockDevice', id=ide0-hd0 }, { 
__jsonclass__: 'BlockDevice', id=ide1-cd0 } ] }

{ execute: connect, arguments: { 'obj': { __jsonclass__: BlockDevice, 
id=ide0-hd0 }, 'signal': 'io-error' } }
{ return: { __jsonclass__: Connection, id=1 } }

{ signal: 'io-error', connection: { __jsonclass__: Connection, id=1 }, 
arguments: { action='stop', ... } }

{ execute: disconnect, arguments: { 'connection': { __jsonclass__: 
Connection, id=1 } } }
{ return: null }

The advantages here are many.  You get much stronger typing in C.  If 
the schema is done right, it trivially maps to an object model in Python.

Regards,

Anthony Liguori

>>> That makes a C centric wire protocol.  Clients don't have to be C.
>>
>> But a C client is by far the most important of all clients--QEMU.  If 
>> we use QMP extensively internally, then we guarantee that the API is 
>> expressive and robust.
>
> No, internally we have the most scope to fix mistakes.
>
>>
>> If we build the API only for third-party clients, we end up with 
>> pretty much what we have today.  An API with good intentions but 
>> that's more or less impossible to use in practice.
>
> Or we have something that's nice for C but hard to use or inconsistent 
> with whatever language a management client is written in.
>