Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Tue, 27 May 2014 05:42:01 +0000 (UTC)
From: "Alexander Shorin (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12716693.1401145418893.20371.1401169321925@arcas>
In-Reply-To: <JIRA.12716693.1401145418893@arcas>
References: <JIRA.12716693.1401145418893@arcas>
Subject: [jira] [Commented] (COUCHDB-2248) Replace "master" and "slave"
 terminology
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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)