On Mon, 2016-09-05 at 17:37 +0200, Erik Skultety wrote: > Hi there, > > after my presentation at KVM Forum, it was pointed out from the audience Disclaimer: I'm the audience in question :) > that we might think about doing something about the naming of the > virt-admin's comands, since there is some sort of inconsistency: srv- > vs. client- vs. dmn- (not merged yet). When I sent patches to upstream I > already knew that the naming was not optimal, but I didn't come up with > anything better so I hoped that the reviewer might think of something > better which unfortunately did not happen. I'm sorry for not paying enough attention at the time and for not raising the issue while the series was still undergoing review. If I had, we wouldn't need to have this discussion :( > Anyway, there are multiple options how this can be approached but I'm > not 100% satisfied with neither of them: > > 1) rename the commands completely > Although clean, obviously this is the non-preferred option because this > would break any backwards compatibility however, I think there is a fair > chance that people haven't actually started using it yet (although that > might change between 7.3 and 7.4). This is very tempting, but I'm not sure we can actually get away with it. > 2) create aliases for non-abbreviated forms of the commands > That way, srv- would become server- and dmn- would become daemon-. > However, by doing this we'll end up with 6 almost identical entries in > the commands structure which might be error-prone once we decide to > add/create&add a flag to the command primitive, since the flag would > have to be added both to the alias and to the original (unlikely, but > possible that someone might forget about that) This seems like a fair solution, but note that I haven't looked at the patch implementing it yet - I might change my mind once I did that ;) > 3) abbreviate client- to something like clnt- > Identical to the above except for the amount of duplicate entries which > would be reduced to 2 I feel very strongly against this option. Not only "clnt" is four letters long, as opposed to the three letters of both "srv" and "dmn", I also think both "clnt" and "dmn" are absolutely unsightly and have no place in a private API - much less in a public one. Not to mention that we will probably end up adding more entitites, that will have to be shortened in the same way, quite possibly with suboptimal results. > 4) leave it as is if such a consensus is reached and accepted > I guess this does no need any additional comments. I feel *even more strongly* about this one :) With all I've written above agains "clnt" and "dmn", I'd rather have those instead of the current inconsistent naming convention. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list