On Mon, 25 Jan 2010 15:33:40 +0100 Markus Armbruster <arm...@redhat.com> wrote:
> Anthony Liguori <anth...@codemonkey.ws> writes: > > > On 01/21/2010 03:09 PM, Luiz Capitulino wrote: > >> """ > >> {"QMP": {"capabilities": ["async messages"]}} > >> > >> { "execute": "query-qmp-mode" } > >> {"return": {"mode": "handshake"}} > >> > >> { "execute": "change", "arguments": { "device": "vnc", "target": > >> "password", "arg": "1234" } } > >> {"error": {"class": "QMPInvalidModeCommad", "desc": "The issued command is > >> invalid in this mode", "data": {}}} > >> > >> { "execute": "async_msg_enable", "arguments": { "name": "STOP" } } > >> {"return": {}} > >> > > > > Maybe: > > > > enable-capability "async messages" > > disable-capability "async messages" > > > > I think that's a bit more obvious and it means that a client doesn't > > have to maintain a mapping of features -> enable functions. It's also > > strange to use an enable command to disable something. > > Agree on both counts. But why two commands? Why not simply "capability > NAME VALUE"? Works even for non-boolean capabilities. I'm not > predicting we'll need such capabilities. I slightly prefer two commands because that's probably how I'd write it in a program (ie. two functions), also enabling/disabling a group of features is a bit easier too, as we can use an array: capability_enable [ "foo", "bar" ] Now, only one command is not terrible difficult, but we would have to accept an array of objects, like: [ { "name": "foo", "enabled": true }, { "name": "bar", "enabled": true } ]