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
