Re: [Qemu-devel] [PATCH 2/2] QMP: Require 'use_unstable' arg for capabilities negotiation

[Luiz Capitulino]

On Fri, 09 Jul 2010 15:24:48 +0200
Markus Armbruster <address@hidden> wrote:

> Luiz Capitulino <address@hidden> writes:
> 
> > On Fri, 09 Jul 2010 10:44:32 +0200
> > Markus Armbruster <address@hidden> wrote:
> >
> >> Luiz Capitulino <address@hidden> writes:
> >> 
> >> > This helps ensuring two things:
> >> >
> >> > 1. An initial warning on client writers playing with current QMP
> >> > 2. Clients using unstable QMP will break when we declare QMP stable and
> >> >    drop that argument
> [...]
> >> Is it really necessary to break all existing users of QMP?
> >
> > The protocol is going to change, they will break anyway.
> 
> Then why break them now in addition to then?

Existing clients? Yes, you have a point. Although our only known existing
client atm is libvirt.

> >> What are we trying to accomplish by that?
> >
> > QMP in 0.13 is in usable state. I fear that people will start using it
> > without noting/caring the protocol is going to be different in 0.14.
> >
> > The removal of this flag in 0.14 (assuming we'll have a stable QMP by then),
> > makes clients break right away, instead of unexpected breaking in subtle 
> > ways.
> >
> > This makes it easy to identify what's wrong and the message will be: you
> > should review your QMP usage, because the protocol has changed.
> >
> > That said, I'm not that strong about this particular solution. What I really
> > would like to have is an easy way to identify old clients using a now
> > stable version of QMP.
> 
> If we want obsolete clients to break when we release 0.14, then let's
> break them then.  No need to break not-yet-obsolete clients now.
> Especially not in a way that unbreaks them in 0.14, when they are
> *really* obsolete.

I don't think we have that many clients today, the only known one is
libvirt. So, this patch takes only new clients in consideration, those
who might start using QMP in 0.13.

Again, I'm ok with a different solution. I just want to go beyond a README file
warning.

What about a "warning" key in the greeting message? Like:

 "warning": "QMP is unstable, it will break soon!"

Not sure it matters as our greeting message is a bit too verbose, but
seems better than nothing.