This terminology problem isn't going away any time soon. Ultimately, the main problem can be summarised by the footnote in the docs - that in many cases it is baked into the protocol, and is therefore hard to change.
Proposal: let the client tell you. We have the HELLO command for connection init. A new option could be added on there to express what the client knows / expects. This isn't really the same as the RESP version, so I propose something like:
HELLO 2 DIALECT 2
Or
HELLO 3 AUTH Foo DIALECT 2
Etc.
Where the DIALECT version controls just the nomenclature in the API, independent of the protocol version (as the raw protocol parser and the expected reply shape are not necessarily handled by the same code layer).
This solves this problem in a future compatible way (meaning: further revisions are possible), and works on RESP2 clients too.
It may be desirable for the server to echo the negotiated dialect version (the max that the client and server both know) in the response to HELLO.
But: in a scenario where both client and server agree on a DIALECT above 1 (the default), it would allow the server to rename all historic but regretted terminology at will.
The downside is that yes, it would have to retain them in DIALECT 1 for back-compat, but: I believe this would be a positive step towards resolving an awkward topic, but which is sensitive to the demands of compatibility. Presumably DIALECT 2 would change response value keys in things like ROLE, INFO, CONFIG, etc.
Thoughts?
I'd also throw in as an aside that while "slave" is the most attention-grabbing command, there is also a lot of impetus at the moment about changing "master" to "primary", "main", or similar. While I know the back-story and previous position in this, it may also be a good opportunity to make that change too. Ultimately (and this is rhetorical): how much energy does redis want to spend defending that choice of terminology, if there's a way to "fix" it?
(obviously I don't care about the specific term DIALECT, that isn't the important thing)
For clients: it would be expected that a DIALECT 2 client still understands and responds appropriately to a DIALECT 1 server; this usually means 2 entries that do the same thing in a switch or similar, so is not tricky. It is assumed that the DIALECT impact / changes would be documented by-version on the HELLO page or similar.
Unknown: how does this impact Lua and modules? Do they assume the behaviour of the related connection, if one? Or is this negotiated in a separate way?
Unknown: what does HELLO do today if an unknown switch is supplied? Does it process the ones it knows and discard the rest? Or does it abandon the entire command? What should it do?
Alternative implementation
If HELLO is not an option due to existing behaviour re unexpected switches, then perhaps a new CLIENT sub-command instead:
CLIENT DIALECT 2
Comment From: antirez
Hello @mgravell, thank you for looking for solutions. My idea is that initially, we should go forward, for Redis 7, to remove completely the mention of "slave" inside the source code. We already don't have any reference in the log messages and in the documentation. Once we do that, how to get rid of "slave" in the remaining places, that are mostly the INFO fields, and the ROLE command?
Well, I think that both commands are one of the most in need for a reshape. I think that Redis 7 should switch to something hierarchical for INFO, and to a much more powerful command for ROLE: ROLE should be deprecated in Redis 7, and a new "REPLICATION" command should be provided, with much more capabilities to show the internals of how the replication is working, both for users and for developers that need more debugging capabilities.
This way we can solve the problem actively improving the system.
I'm not sure with changing "master" right now however, because we did a lot of efforts recently to remove the "slave" term, and "master" was acceptable, maybe "master" in the long run will be considered a word that is ok by the community? Let's see what happens. Now to do again the same work for "master" gives the feeling that the amount of work to replace words is unbound, because tomorrow we can get a new word, and we can't do that again and again. While in the end I wanted to replace "slave" to give a positive feedback to certain users, I also have to give something to people that don't really believe this is actually helping. To change every term that is, in a given moment, no longer considered ok, would be terrible for such part of the community that feel that we are creating problems and wasting energy with such tasks. So I think the first step is to do the full work on "slave", that we already started and want to complete. And later evaluate what to do with master, but with some perspective, since now we are in a very complex moment where maybe there is an hyper-reaction to such issues.
Thanks