On 07/23/2015 09:44 PM, Eric Blake wrote:
> 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.
> 

>>  
>> +import string
>>  from qapi import *
>>  
>> +def _b32digit(num):
>> +    return (string.lowercase + string.digits[2:])[num]
> 
> This feels a bit too magic for me to decipher late at night.

Looking at this again after a weekend: you are doing a poor-man's base32
encoding that maps a number between 0 and 31 inclusive to
"abc...xyz234567" (skipping 0 and 1 due to some fonts being unclear with
O and l/I).

Question - if we really want to compress things down to an integer,
would it make any more sense to actually use an integer instead of a
string encoding of an unusual base32 alphabet (that is, output an
integer instead of a string)?  Conversely, if we are going to insist on
an encoding, can we use the RFC4648 base32 definition (upper case, not
lower case)?

More thoughts: I'm probably okay with hiding type names (since they
aren't ABI), but can we come up with an output format that is more
conducive for use by the end user?  Considering that we are returning a
JSON array, what if we return the integer offset of the type as recorded
in the returned array.  That is, if we have
 { 'name':'ACPI_DEVICE_OST', 'meta-type':'event', 'data':100 }
in slot [0] of the return array, then
 { 'name': ':aaa', 'meta-type': 'object', 'members': [ { 'name': 'info',
'type': 250 } ] }
in slot [100], then the definition for type ':ae5' in slot [250], and so
forth.  My goal here is not a topologically sorted return array, so much
as a shorthand where using an integer for a type-name means that we can
quickly locate that offset within the JSON array, instead of having to
do a linear search over the entire array for an array member that has
the matching name.  Or if type names are truly unimportant, then omit
names for type elements (by making name optional in the introspection
qapi description), and using ONLY offsets in the returned JSON array for
referring to types.  Of course, if we do this, life gets a lot trickier
for adding filtering down to a subset of the overall schema (unless you
don't mind populating lots of 'null' entries for parts that get filtered
out so that the parts that are displayed are always at the same array
offset, just with less overall output bulk due to the filtering).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org