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 > > 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. On output from the server, we can add new fields (such as more details about an error message), and old clients should ignore extra fields. Meanwhile, these fields should be documented as optional, so a new client can be prepared to deal with an older server that didn't send the field. So yes, it really does sound like you want different behavior depending on whether it is the client or the server that is originating the new fields. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
