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

[Markus Armbruster]

"Michael S. Tsirkin" <address@hidden> writes:

> On Thu, Sep 24, 2009 at 03:28:40PM +0200, Markus Armbruster wrote:
>> 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.
>
> If we use this to supppress/enable messages, I think
> it's clear we need to support changing them on the fly.
>
>> 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?
>
> For debug messages, sending and discarding them might have
> performance impact.
>
>> 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.
>
> Some kind of version is the usualy way to do this.

A version number covers only server offering capabilities, not client
accepting them.

If clients discover capabilities through version numbers, selective
backporting becomes awkward.

In my experience (whatever that's worth), protocols that start out
without capability negotiation get it retrofitted when they evolve.

The expected cost of retrofitting might be lower than the cost of doing
it right from the start.  I really don't want to turn this into a big
argument now.