On Wed, Aug 21, 2013 at 10:46:36PM +0200, Giuseppe Scrivano wrote: > Eric Blake <eblake@xxxxxxxxxx> writes: > > > I'm not sure whether returning XML or a straight-up list makes more > > sense. If you used char ***models, then the user would get an array of > > directly-usable strings, "486", "pentium", ..., instead of a document > > that has to be parsed. On the other hand, your idea of returning XML > > lets us return information for multiple arches simultaneously. But do we > > need that flexibility, since arch is also an input parameter? Is the > > idea that you pass arch=NULL to get the full list, or arch="x86" to get > > the x86 subset of the xml? Why not just make arch mandatory and return > > char ***; but then you have the question of which arches are supported. > > I've thought a bit about XML vs Array and whether specifying the arch in > the returned XML snippet or not, and these are the reasons behind my > choice: > > 1) leave room for VIR_CONNECT_GET_CPU_MODEL_NAMES_EXPAND_FEATURES, in > the same way as it is done by virConnectBaselineCPU. It might turn > useful in future to get all the data in one shot, without requiring > additional round-trips for each model trough virConnectBaselineCPU. I don't think returning a list of all cpus with all features is an operation that will be common, or performance critical. So do not want to see us replicating virConnectBaselineCPU functionality here. > 2) as you said, support arch=NULL to get the full list (and now that > I've thought more about it, I should change the error to > VIR_ERR_NO_SUPPORT when arch==NULL instead of raising an internal > error). I'd strictly forbid arch=NULL in the API and wire protocol (ie use remote_nonnull_string arch). Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list