Re: [Qemu-devel] [PATCH RFC v2 47/47] qapi-introspect: Hide type names

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> 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)?

I don't remember why I did lowercase.  Possibly an accident at the tail
end of a mad hacking spree.  Uppercase is fine with me.

Could do plain integer.  I guess I started down the base32 road to
squeeze out a few more characters, then sabotaged myself by always using
three base32 characters.

> 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.

In the introspection schema, every 'str' that's really a type name needs
to be replaced by 'int'.

Should we later decide we don't want to hide type names after all, then
backward compatibility will make it very hard to go back.

I wouldn't expect clients to find stuff with a linear search.  Use a
dictionary.  Should be plenty fast enough for processing the schema.

>                     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).

Filtering is a headache I'd prefer to avoid.