> Would you describe universal semantics as being "Turing-complete in the context of a distributed system"? Food for thought! But note Universal in context of

> Would you describe universal semantics as being "Turing-complete in the context of a distributed system"? Food for thought! But note Universal in context of EC-AP. That said, turing completeness also gives us the halting problem, which in context of a distributed systems seems to map to FLP impossibility and transaction finalization. (Just musing here, please note). If we're to insist on a robust notion of "gurantees" here, then prudence seems to suggest a weaker computation model is more appropriate. > availability is not such a shaded guarantee as consistency is. I regard availability as a black & white property, whereas consistency is a whole spectrum of colours. I definitely see the validity of that point of view but then question the insistence that (capability) availabilities should be seen as all or nothing. For example, what to make of a partially available systems? If you are old enough you may remember "all circuits are busy" when making international calls, but your calls to the local area network were still available. Of course (re. colors), when we start looking at availability as measure, it is not a continuum, but rather a discreet space where progressively richer interaction semantics become available. > Consider the following example. Say you're using MySQL (a CP system) and you also have a client-side cache (essentially AP). We're in agreement here. First let's note it is 'turles all the way down', since e.g. your persistence subsystem at the OS/HW level (that your AP or CP system depends on) is at this point a miniature distributed system so this dance of availability and consistency (such as whether the OS or the SSD both agree that a certain block has such and such value) continues until we hit deterministic devices. To be concrete, consider fsync's consistency guarantees in the practical context of modern hardware and OS and virtualization. End-to-end principle can inform us here. The interaction semantics are affected at precise delinations in the system. It should not matter that behind the facade there is MySql or just plain jane mmap'ed files. You, as the programmer, are modeling an interaction via a specific set of interfaces. So if at the system surface level you are interacting the characteristics are AP, it is irrelevant if the inner workings of the system are CP. That said .. > Now it's not clear to me why you need the make the distinction between CP and AP. ICG is orthogonal to these categories. Possibliy because of the C in ICG :) A CP system can only be inconsistent if it is faulted. I am having difficulty in understanding how/why a non-faulty CP system would have incremental consistency states. > I'll now run the risk of taking it maybe a bit too far: but I think whenever an application chooses a consistency model, that model inherently comes along with its own preset availability guarantee. As consistency models get stronger, there is an instant switch from available to non-available models. [I should cite some refs here but I'm in a hurry.] Consequently, if you have incremental consistency guarantees then you also have decreasing availability guarantees. I think we're in agreement here.