On 03/10/2011 05:41 PM, Anthony Liguori wrote:
I also think it should be at the protocol layer:
> { execute: some-command, id: foo, arguments: { ... } }
< { result: { ... }, id: foo }
> { subscribe: block-io-error, id: bar, arguments: { ... } }
< { result: { ... } id: bar }
< { event: block-io-error, id: bar, data : { ... } }
> { unsubscribe: block-io-error, id: bar }
< { result: { ... } id: bar }
So events are now protocol-level pieces like commands, and the use of
tags is uniform.
Maybe for QMPv2, but for QMPv1, this is going to introduce an
extremely incompatible change.
Why? It's 100% backwards compatible.
Actually, we missed the json-rpc boat in designing QMP. It should
look like:
IIRC I looked at it and it didn't impress me.
> { method: some-command, id: foo, params: { ... } }
< { result: { ... }, id: foo, params: { ... }, error: null }
> { method: connect-block-io-error, id: bar, params: { ... } }
< { result: { ... }, id: bar, error: null }
< { method: block-io-error, id: null, params: { ... } }
Keys are different and null is passed instead of not including a tag.
Events are sent exactly like methods but id is null. A result is
never sent to the server for an event.
That means that we need a per-event command, instead of making it
protocol-level.
One of the good things about using a code generator and IDL though is
that we can add a -qmp dev,protocol=json-rpc that encodes
appropriately. We can probably do this translation at the QObject
level really. But in the future, we can also add -qmp
dev,protocol=xml-rpc, -qmp dev,protocol=rest, or -qmp
dev,protocol=asn1-rpc
Let's get one protocol that works first.
--
error compiling committee.c: too many arguments to function
