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