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

[Markus Armbruster]

Eric Blake <address@hidden> writes:

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

We could use an alternate.  Feels like gratuitous complexity to me,
though.

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

I'll try and see how that pans out.

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

For completeness: dictionary needn't be implemented as hash table.

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

Okay.  Thanks!