[Abstract]

    ActiveMQ 5 and Artemis are both re-working legacy terminology to better 
describe function and move away from problematic language for shared storage 
and replication terminology indicators.

[Background]

    JIRA discussion: https://issues.apache.org/jira/browse/AMQ-7514 
<https://issues.apache.org/jira/browse/AMQ-7514>
    Mailing list: 
http://activemq.2283324.n4.nabble.com/DISCUSS-Draft-proposal-for-terminology-change-td4758351.html
 
<http://activemq.2283324.n4.nabble.com/DISCUSS-Draft-proposal-for-terminology-change-td4758351.html>

[Proposal]

    P-1. Broker layer will maintain a status— ‘active’ or ’standby’ based on 
signals from persistence layer
 
    P-2. Persistence layer will optionally provide a noun and verb based on the 
underlying technology's terminology.

    P-3. ActiveMQ project created persistence layers that support replication, 
the terminology should attempt to provide noun and verb terms to describe the 
mode and state.
            Mode: ‘primary’ and ‘replica’ 
            Status: ‘active’ and ’standby'

[Scope]

    S-1. Terminology alignment between ActiveMQ 5 and Artemis is only for 
shared storage, replicated storage, broker status, and future terms.

[Benefits]

    B-1. Terms for Broker state will be aligned between ActiveMQ 5 and Artemis 
free of problematic language.

    B-2. Terms for replication will bubble up “as-is” based on the underlying 
persistence layer technology. 

    B-3. If both ActiveMQ 5 and Artemis use the same replication tech, then 
terms will be aligned. 

    B-4. If one provides a persistence layer adapter that the other does not 
there is no phantom noun or verb present on the other broker that has no direct 
technical meaning

[Rationale]

   R-1. Attempting to create common terms may leave one broker with a phantom 
term that has no meaning
 
   R-2. Attempting to create common terms is problematic when two supported 
persistence adapter layer technology use different terms (leader / follower, vs 
primary / replica).

   R-3. Renaming terminology that is not problematic for the sake of alignment 
(ie. acceptor vs transportConnector) unfairly creates burden on the existing 
user base.


Thank you,
-Matt Pavlovich

Reply via email to