[
https://issues.apache.org/jira/browse/COUCHDB-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14009297#comment-14009297
]
Alexander Shorin commented on COUCHDB-2248:
-------------------------------------------
-1 That's overplaying. Both ["master" and "slave" |
http://en.wikipedia.org/wiki/Master-slave_%28technology%29] are well known
computer science terms with single point of interpretation. Please don't taint
them with own feels and arguments that they're also been used in different
context. Otherwise we'll fight for every word (fearing that it may hurt or
being misunderstood by anyone of 7 billion Earth population) without making any
progress.
If they hurts anyone I suggest the next:
1. Close the Internet: Master and Slave are basic DNS terms: RFC 2136, RFC 1996
2. Stop sync your time on all your devices: RFC 5905
3. You need to stop using Microsoft Windows, because basic workgroup network in
based on Master-Slave relations. See NetBIOS.
------------------------------------------------------------
Now about the topic.
I suggest to not invent new terms and use well known ones to not being
misunderstood be technical community as we are. So let's think and act in this
boundaries. What is Master-Slave communication? In common:
- Master is the authoritative source of information, mostly with R+W bits;
- Slave is the copy of Master data which remains *READ ONLY* which cannot
maintain own Master-Slave bounds
You may find similar to these definitions and restrictions in every
Master-Slave system.
As for CouchDB the Slave isn't actually Read-only system - it still can change
the received from the Master data, it can setup own "Master-Slave" replication
with others => it's doesn't acts like a classic Slave, but like a classic
Master.
In [RFC3040 |http://tools.ietf.org/html/rfc3040] there is good definition for
such case:
{{quote}}
master origin server
An origin server on which the definitive version of a resource
resides.
replica origin server
An origin server holding a replica of a resource, but which may
act as an authoritative reference for client requests.
{{quote}}
Applying Replica term instead of Slave makes things more clear and closer to
reality. Replication still remains "Multi-Master", but instead of
"Master-Slave" we can use "Single-Master" term which includes "Replica"
creation, but not requires to explain "Slave" thing.
Also see [LDAP Multi-Master Replication
Protocol|http://tools.ietf.org/html/draft-ietf-asid-ldap-mult-mast-rep-02]
> Replace "master" and "slave" terminology
> ----------------------------------------
>
> Key: COUCHDB-2248
> URL: https://issues.apache.org/jira/browse/COUCHDB-2248
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Documentation
> Reporter: Noah Slater
> Priority: Trivial
>
> Inspired by the comments on this PR:
> https://github.com/django/django/pull/2692
> Summary is: `master` and `slave` are racially charged terms, and it would be
> good to avoid them. Django have gone for `primary` and `replica`. But we also
> have to deal with what we now call multi-master setups. I propose "peer to
> peer" as a replacement, or just "peer" if you're describing one node.
> As far as I can tell, the primary work here is the docs. The wiki and any
> supporting material can be updated after.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
