couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Shorin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-2248) Replace "master" and "slave" terminology
Date Tue, 27 May 2014 05:42:01 GMT

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

Mime
View raw message