Am 15.09.2014 um 03:31 hat Fam Zheng geschrieben: > On Sat, 09/13 19:04, Markus Armbruster wrote: > > > > I actually like having separate parameters for separate kinds of names. > > > > However, BlockdevRef appears to tie our hand: it's an anonymous union, > > which means only the value is on the wire, and the receiving end uses > > its type to determine which union member it is. Both kinds of names are > > strings, so we can't have separate union members for them. > > > > Opinions? > > Why wouldn't it work without distinguishing it in the QAPI side?
BlockRef takes either a string referring to an existing BDS (using device_name or node-name) or a dict of options for creating a new one. > I remember at the time of introducing node-name, it was in a separate > namespace, but now it's not. Then why should the user care *whether* a name is > "device" or "node-name"? When you reconfigure the graph (e.g. by taking a live snapshot), the BB name always stays at the root (i.e. points to the new BDS), whereas the node-name always stays at the same node (which was at the root, but isn't any more), that's probably important for the user. Maybe a bit like branches and tags in git. So yes, they are somewhat different, but in the end they all resolve to a BDS and it makes sense to allow accessing them in a uniform way (just like 'git show <tag-name>' works the same as 'git show <branch-name>'). Which leads me to this conclusion: One mandatory string argument per command is enough, and also results in a cleaner interface than having two optional arguments that aren't truly optional because you need to specify the one xor the other. Kevin
