On 07/28/2015 12:24 PM, Markus Armbruster wrote: > Eric Blake <ebl...@redhat.com> writes: > >> On 07/01/2015 02:22 PM, Markus Armbruster wrote: >>> To eliminate the temptation for clients to look up types by name >>> (which are not ABI), replace all type names by meaningless strings. >>> >>> Reduces output of query-schema by 9 out of 80KiB. >> >> I'm not sure whether I like this or not. It does make sense from the >> perspective of forcing clients to stick to ABI queries, but makes it a >> bit harder to navigate things except by automated scripts. > > Yes. I'm not sure it's a good idea. If we decide to hide types this > way, then I'd find an option to generate without type hiding useful.
As in, an optional boolean flag to the QMP command that requests whether to get compact output with hidden names vs. full output with qapi names exposed (but then, are we storing TWO copies of the introspection strings)? Or merely as in the generated qmp-introspect.c file having strategic comments so that reading _that_ file lets you see the type names, even if they don't get passed on to the end user? > What the patch adds: > > Move the introspection information for the non-types out of the way > before the loop, append the information on types afterwards. The result > is now in jsons rather than self.jsons (see the next patch hunk). I did notice that; pre-patch interleaved commands and types all according to a global namespace, while post-patch sank all types to the bottom. Interestingly enough, if libvirt is going to query what features a command has, it will first find the command (in the first half of the returned array), then resolve the types used by that command until it learns if the member is present (whether new enum value or added dictionary member) - so there is that slight optimization that if we guarantee that types are always output last, then libvirt doesn't have to start generating its own hash table lookup of types until the first type is seen, after already learning everything it needed from the earlier command listings. > > Why it does that: > > With the funny typenames, sorting everything by name results in a mess. > Keeping non-types and types separate is less of a mess. You do have a point there - as soon as we introduce name aliases, the aliases are unlikely to sort in the same manner as the original types, particularly if we generate the aliases based solely on what order we detected that those particular types were in use. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
