Re: [Ilc] Clarifications and thoughts purpose of ILC list

[Tony Arcieri <[e-mail]>]

On Thu, Feb 23, 2017 at 11:25 AM, David Mazieres <
[e-mail]> wrote:

> I agree about CP, but not AP.  AP systems are not safe, and hence will
> clobber data.
>

Correctly designed AP systems support a merge operation to reconcile
disparate states. CRDTs are an example of a system that can always merge
data automatically in a conflict-free manner. In absence of that you need a
domain-specific user defined merge function.

That said Last Writer Wins is a popular strategy in systems describing
themselves as AP, and exhibits this sort of data clobbering behavior. I'm
not sure such systems should describe themselves as partition tolerant,
though.

Right, so basically you are saying any Internet-level consensus
> mechanism should guarantee safety even in an asynchronous communication
> model where you can't distinguish slow from failed nodes.  I agree,
> personally.  However, reasonable people might push for greater
> availability.  It would be interesting to see if list members have
> "rough consensus" (non-technical meaning) on this point, or
> alternatively if makes sense to layer a less safe but more available
> "short-term" system on top of one that guarantees safety for long-term
> events (e.g., for certificates issued over a week ago).  We may want to
> revisit this question down the line after discussing more applications.


The main option, which is particularly applicable to systems which publish
to read-only clients, is to allow stale reads. This flips the semantics
from CP to AP, allowing inconsistent views of the current state of the data
(i.e. sacrificing consistency for availability), but should be safe if data
being read is not incorporated into subsequent writes (i.e. stale reads are
only allowed by truly read-only clients)

-- 
Tony Arcieri