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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Thu, 24 Sep 2009 15:28:40 +0200
Markus Armbruster <armbru@redhat.com> wrote:

> Luiz Capitulino <lcapitulino@redhat.com> writes:
> 
> > On Thu, 24 Sep 2009 00:37:53 +0200
> > Markus Armbruster <armbru@redhat.com> wrote:
> >
> >> Luiz Capitulino <lcapitulino@redhat.com> 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.

 Maybe it's better, but I'm wondering if it's worth it, considering the
implementation and usage "complexity".

> 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. 

 This is true, although I think it's a good practice for programs to
start QEMU in pause mode and only put it to run after some setup is
done.

 This also has to be considered with the handshake approach, eg.
if QEMU is started before the application connects to it, we will
have a window of time where several things may have happened in
QEMU and this may affect the protocol. Async messages is an example.

> If I have to ignore them anyway, why bother with disabling them?

 I can see two separate things here: 1. do we need/want the
handshake approach? 2. Should async messages be considered a
capability?

 If disabling async messages is not needed, then it should
not be considered a capability.
 
> 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.

 Why? Enabling 'what you want' as suggested by Avi doesn't have the
same end result?