Eric Blake <ebl...@redhat.com> 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!
