should "client" be removed from the end of Cask names?

[rolandwalker]

@vitorgalvao and all interested folks:

Should the term "client" be stripped from the end of Cask names?

• Argument pro: it is a somewhat generic term which is less helpful in search.
• Argument con: predominant existing practice is to keep it in.

My inclination when choosing between these two is is "argument con", ie run with existing practice, because that leads to the goal systematic naming with the fewest possible disruptive rename events.

Also, "client" is not a hopelessly generic term. In the case of a VPN (below), perhaps the user finds client vs server quite important to know at first glance in search.

But I can be persuaded either way: so long as there is a rule.

Current Casks that drop trailing "client" from the name:

• seafile.rb
• strongvpn.rb

Current Casks that keep trailing "client" in the name:

• cocoarestclient.rb
• curse-client.rb
• quassel-client.rb
• teamspeak-client.rb
• tk-suite-client.rb
• wiztoolsorg-restclient.rb
• wowhead-client.rb

(context: following up on #3285, #2659, #3175, and #3255)

[alebcay]

I think "client" should stay if there is a server version (that is an app and could be submitted as a Cask) for whatever it happens to be available also. If the server is some CLI tool, it's unlikely that there would be confusion. For example:

• StrongVPN doesn't have server software available (I'm pretty sure it's a service, and the client is just the user front-end).
• The same logic applies for curse-client, for which I don't believe there is a server either (again, not a server - there's no way someone could confuse it for something else).
• seafile should stay the way it is (without "client") because no OS X version of the server software exists, or one could argue that "client" should be added to avoid confusion with the server version anyways.
• quassel-client should retain "client" because there's a "core" version of the software too.

[vitorgalvao]

The word “client” is also of help when determining the type of app, as it implies an application that is an interface to deal with some external service. Having said that, I don’t feel strongly either way.

Contrary to this one, though, the other issues have clear-cut rules, and well defined exceptions. I mention this since it might be somewhat unpredictable to users when some apps have “client” in the name and others do not, solely based on if there’s a “server” (or something else) version or it (that they might not know of or care about). Some of these would even look a bit weird without the word “client” (the “rest” apps), which would make the decision even more based on what looks right on a case-by-case basis, instead of some underlying consistency.

If I had to pick one, I’d go with keeping “client” in all of them, but again, I’d be fine with any decision.

[rolandwalker]

Great! We keep "client" (no new rules needed, also a virtue).

@alebcay your points make perfect sense, but I'm looking for a simple rule that removes judgment calls and contextual info from the equation -- because my goal is a script.