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

[Avi Kivity <avi@redhat.com>]

On 03/10/2011 06:04 PM, Anthony Liguori wrote:
> 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.

It would be much better to avoid introducing deprecated commands.  
They're a maintenance burden for both server and client, and a testing 
burden as well.  I feel it's better to spend more time to get something 
we truly like.


>
>>
>>> 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.

I note that connect is not protocol level (i.e. execute: connect, 
signal: io-error instead of connect; io-error).

Regarding class hinting, I don't object to that, but I feel that the 
schema provides all of the benefits already.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.