Re: [Qemu-devel] ANN: QEMU Monitor Protocol git tree

[Markus Armbruster]

Luiz Capitulino <address@hidden> writes:

> On Thu, 24 Sep 2009 00:37:53 +0200
> Markus Armbruster <address@hidden> wrote:
>
>> Luiz Capitulino <address@hidden> writes:
>> 
>> [...]
>> > 2.2 Server Greeting
>> > -------------------
>> >
>> > Right when connected the Server will issue a greeting message, which 
>> > signals
>> > that the connection has been successfully established and that the Server 
>> > is
>> > waiting for commands.
>> >
>> > The format is:
>> >
>> > { "QEMU": json-string, "QMP": json-string, "capabilities": json-array }
>> >
>> >  Where,
>> >
>> > - The "QEMU" member contains the QEMU version
>> > - The "QMP" member contains the QMP version
>> > - The "capabilities" member specify the availability of features beyond the
>> >   baseline specification
>> 
>> What about capability negotiation?  Server offers capabilities, client
>> can accept or decline them.
>> 
>> [...]
>
>  I think the easiest way to have this would be to add a
> monitor command to disable capabilities. Like a command to
> disable async messages.

Greeting capabilities (for lack of a better word) are for the protocol.
Changing protocol capabilities while you use the protocol is awkward.
Better do it in an initial handshake.

Case in point: if you disable asynchronous messages with a command, you
still have to be prepared to receive one between initial handshake and
completion of the disable command.  If I have to ignore them anyway, why
bother with disabling them?

The problem becomes more serious if we ever want to add a capability
that isn't fully backward compatible.  Lack of feature negotiation
limits protocol evolvability.