On 07/17/2013 02:36 PM, Luiz Capitulino wrote: >> We need to parse all commands json definition, and generated a >> dynamical tree, QMP infrastructure will convert the tree to >> json string and return to QMP client. >> >> So here I defined a 'DataObject' type in qapi-schema.json, >> it's used to describe the dynamical dictionary/list/string. > > I skimmed over the patch and made some comments, but my impression > is that this is getting too complex... Why did we move from letting > mngt query type by type (last version) to this version which returns > all commands and their input types? Does this satisfy libvirt needs?
Libvirt can query once, and then browse through the (giant) reply as many times as needed to drill down to a full definition. The ability to filter by passing in a name to look up is a bonus, but not mandatory. I'm also working on a reply to the full patch. > You return only commands. That is, types are returned as part of the > command input. ErrorClass can't be queried then? I'm not judging, only > observing. > > Eric, this is good enough for libvirt? It might be sufficient (after all, you can't use a type except by passing it as part of a command [argument or return] or event [which we still don't have converted into qapi...]). In one respect, it means that if we want to know if an optional field was added for command 'foo', we start by querying command foo; then regardless of what type names were used, we will see that in the results for the command. On the other hand, we've been arguing that qapi type names are part of the API, and that we shouldn't arbitrarily change type names (particularly not once introspection is in place). Thus, if I can query for the contents of type 'FooDict', that shaves a step from querying the structure of command 'foo' that uses the type 'FooDict'. In other words, it will "work" for libvirt, but it may not be optimal. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
