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.