From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35680) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9j6B-0003M7-Su for qemu-devel@nongnu.org; Mon, 19 Mar 2012 16:22:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S9j69-0004c0-N7 for qemu-devel@nongnu.org; Mon, 19 Mar 2012 16:22:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32676) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9j69-0004bo-Ew for qemu-devel@nongnu.org; Mon, 19 Mar 2012 16:22:33 -0400 Message-ID: <4F679576.60900@redhat.com> Date: Mon, 19 Mar 2012 14:22:14 -0600 From: Eric Blake MIME-Version: 1.0 References: <1332185368-18708-1-git-send-email-pbonzini@redhat.com> <4F678A37.1020101@codemonkey.ws> <4F678E38.7050902@redhat.com> <4F678F6A.3050804@codemonkey.ws> In-Reply-To: <4F678F6A.3050804@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig7C52A5C641D70B0A2D0BA190" Subject: Re: [Qemu-devel] [RFC/RFA PATCH] qapi: detect extra members inside structs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Paolo Bonzini , lcapitulino@redhat.com, Michael Roth , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7C52A5C641D70B0A2D0BA190 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/19/2012 01:56 PM, Anthony Liguori wrote: >> For old clients that could be fine. But what about old servers? :) >=20 > 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 >=20 > 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 libqap= i > in terms of enforcing compatibility rules. >=20 > 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. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig7C52A5C641D70B0A2D0BA190 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPZ5V3AAoJEKeha0olJ0NqyoMH/jLvsnLWoTYkXZ8+MbbeMxAn +ze0HmGA74605tRfNO+ph3XjqNPh3rk2XvhwyOjv8i4V6KfVRFxN7JupktsttSO4 eSk1ON4ApSibshP9yqwAgOG+V9Eviy/7WaMonCBLgfkJHV29+A4yw61c2gGs/PVS NEHY3i1p06/By3bY5F2hEexvP4KQi64e6xsOpnE4T8mr6ka/txKWr2BWAojiBEFw TR2Dk9FptLQiKjfDP0FF3L3QiLa1TWRnh9J5aI4BUIQRE54YK+w/f3Nkia4Q12Zr pBWXWqj873ej+IwHmeyQN4aGvTQXiHErtewqR7Le+trtNwpaaKEmNKUUIsMjKj4= =2KuQ -----END PGP SIGNATURE----- --------------enig7C52A5C641D70B0A2D0BA190--