From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37820) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXXt9-0002kl-AC for qemu-devel@nongnu.org; Thu, 03 Sep 2015 13:01:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXXt6-0005HW-59 for qemu-devel@nongnu.org; Thu, 03 Sep 2015 13:01:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41419) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXXt5-0005HJ-Ue for qemu-devel@nongnu.org; Thu, 03 Sep 2015 13:01:24 -0400 From: Markus Armbruster References: <1438703896-12553-1-git-send-email-armbru@redhat.com> <1438703896-12553-31-git-send-email-armbru@redhat.com> <20150901184026.18566.39890@loki> <55E5F898.6040304@redhat.com> <20150901202348.18566.60300@loki> <87io7t42t2.fsf@blackfin.pond.sub.org> <20150902162156.11972.58160@loki> <87r3mfyhty.fsf@blackfin.pond.sub.org> <55E859A5.9060807@redhat.com> <20150903155932.11972.308@loki> Date: Thu, 03 Sep 2015 19:01:20 +0200 In-Reply-To: <20150903155932.11972.308@loki> (Michael Roth's message of "Thu, 03 Sep 2015 10:59:32 -0500") Message-ID: <87egifl9nj.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH RFC v3 30/32] qapi: New QMP command query-schema for QMP schema introspection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: kwolf@redhat.com, berto@igalia.com, qemu-devel@nongnu.org Michael Roth writes: > Quoting Eric Blake (2015-09-03 09:31:01) >> On 09/03/2015 03:26 AM, Markus Armbruster wrote: >> >> >> >> I think we need to be careful that these descriptions are not >> >> interpreted by clients as an alternative to the more-specific >> >> constraints in the QAPI schema though. 'query-schema' seems >> >> a bit misleading in that regard, it appears to be more like >> >> 'query-schema-encoding' in function. But not sure it's worth >> >> renaming or anything so long as the documentation is clear. >> > >> > You have a point: "schema" can mean two related, yet different things. >> > There's the QAPI schema, and there's the QMP (the wire protocol) schema. >> > QMP introspection is about the latter, not the former. >> > >> > If we want to avoid the ambiguity, we could call the command >> > query-qmp-schema or something. >> > >> > Renaming query-schema now might confuse people coming from my KVM Forum >> > talk slightly, but if we can agree on a better name, let's do it. >> >> I'm okay if you want to use 'query-qmp-schema'; it's a bit longer, but >> more precise, and doesn't cause too much grief to change the name at >> this point in the game. > > I'm also okay with this. It avoids confusion down that road if we > ever introduced, say, a query-ber-schema or something. > > I have some minor reservations: I think query-qmp-schema-mapping or > query-qmp-schema-encoding, i.e. "give me information on how the > [QAPI] schema maps to the QMP wire protocol", is more correct. > query-qmp-schema reads like "give me the complete schema for the > QMP wire protocol", which makes it more tempting to treat the > result as a complete schema, rather than a component of what's > defined by the QAPI schema. Well, it *is* the schema for the QMP wire protocol. Which happens to be mechanically derived from the QAPI schema. > But in all likelihood trying to cram all that information into the > command name would probably just be confusing to most, so a simpler > name with clear documentation seems reasonable. I think query-qmp-schema hits the sweet spot between "ambiguous because it's too short" and "too long because we tried to make it unambiguous". I'll adopt it in v5. Regarding clear documentation: we don't have to get it perfect in the initial commit, but I'm of course happy to address review of RFC PATCH v4 in v5.