[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command
Date: Sat, 12 Mar 2011 22:42:33 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]