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

[Eric Blake]

On 07/28/2015 12:39 PM, Markus Armbruster wrote:

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

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

Sadly, our introspection union is based on 'name':'str',
'meta-type':'...' as the base members of the union; and that 'name'
would be one of the places where we'd want an integer; so we probably
have to stick to a string.  That said, using a string-ized integer may
be a bit more legible (for some reason, humans are better at reading
decimal numbers than base32 numbers), and since no valid command or
event starts with an integer, we could use the stringized integer
directly without having to use a colon (in fact, for the first 999 types
encountered, a stringized integer is shorter than the base32 compression
+ the leading colon for namespacing) :)

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

Indeed - changing 'str' to 'int' in the schema is a much stronger
commitment than leaving things 'str' but passing a stringized integer in
that string.

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

Requires more memory in the client to create that hash table on the one
pass through the JSON - but as is often the case in computer science,
asking the client to trade space for time is not too onerous.
(Libvirt's current JSON parser does NOT create a hash table of the
dictionaries that it reads, so libvirt would actually have to do two
passes and/or update its use of libyajl into creating hash tables when
appropriate - but that should not be a driving factor in your design.)

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

Well, since I've had most of the ideas about how filtering could even be
done, I'm perfectly okay with you leaving the guts of filtering for me
(or someone else) to do as a followup series; and even then, I first
have to decide if it would help libvirt to have a filtered list.  What's
important for this series is that we haven't precluded the possibility
of adding filtering later, and I think we've succeeded at that.  And as
for using raw integers to represent offsets into the returned JSON
array, I think that is a bit too brittle; so I'm happy with forcing
clients to create their own dictionary/hash lookup of string type names,
even if the strings are munged to avoid leaking qapi types as non-ABI.

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

signature.asc
Description: OpenPGP digital signature