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

[Avi Kivity]

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.