On Mon, 19 Mar 2012 15:30:26 -0500
Anthony Liguori<address@hidden> wrote:
On 03/19/2012 03:22 PM, Eric Blake wrote:
On 03/19/2012 01:56 PM, Anthony Liguori wrote:
For old clients that could be fine. But what about old servers? :)
Same applies to old server. If a new client tries to use a new field,
if the old server refuses it, then the new client breaks.
I recently asked this question, and I was told that it is a feature that
unknown fields attempted by a new client are rejected by an old server:
https://lists.gnu.org/archive/html/qemu-devel/2012-03/msg00815.html
Unfortunately that's not entirely correct.
The QMP server has a mechanism to validate that the input parameters that are
passed conform to the spec in qmp-commands.hx, but this spec can only handle
simple types. Anywhere where we bypass this check (like we do for transaction),
the checking is up to the callee which doesn't check.
Right.
There's no way in QMP to detect whether a server supports a new field.
This is why I proposed instituting a policy of never adding/removing
fields to structures and why I had advocating use a C version of libqapi
in terms of enforcing compatibility rules.
I'm not sure if the "server ignores unknown" fields thing is even
reasonable to rely upon so maybe we should just draw a line in the sane
and make the change you're suggesting...
For ideal back-compat, I think you want:
On input to the server, we can add new fields, but such new fields must
be optional (old clients that omit the fields get the default value,
rather than a new server rejecting the command due to a missing field).
The question arises when you have a new client talking to an old
server; here, I think it's better to _always_ have the server reject
things it doesn't recognize, so that clients can use this rejection as a
feature probe, and then you _do_ have reliable ways of querying whether
a feature was added, by whether the new argument associated with that
feature is present.
The problem is that this requires transactional semantics such that if the
command fails, there are no side effects. I don't think we're in a position to
guarantee that.
IMHO failing with side effects is a bug. Although no command that does that
comes
to my mind right now.
I'd greatly prefer to simply not add new options to existing commands. It's
simple, maps well to how we do things in C, and is easy to enforce.
We extensively discussed this some months ago. I honestly don't want to repeat
that discussion. So, if there's consensus that adding new commands is better
than extending existing ones, this is fine with me.
Another solution would be to extend query-commands with arguments info, which
is something that I think we will do soon or later...