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

[Michael S. Tsirkin]

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.

-- 
MST