Rebuild

output/abstractions.html

@@ -243,7 +243,7 @@ <h3>Strong consistency models</h3>
 <p>All the other consistency models have anomalies (compared to a system that guarantees strong consistency), because they behave in a way that is distinguishable from a non-replicated system. But often these anomalies are acceptable, either because we don&#39;t care about occasional issues or because we&#39;ve written code that deals with inconsistencies after they have occurred in some way.</p>
 <p>Note that there really aren&#39;t any universal typologies for weak consistency models, because &quot;not a strong consistency model&quot; (e.g. &quot;is distinguishable from a non-replicated system in some way&quot;) can be almost anything.</p>
 <h3>Client-centric consistency models</h3>
-<p><em>Client-centric consistency models</em> are consistency models which involve the notion of a client or session in some way. For example, a client-centric consistency model might guarantee that a client will never see older versions of a data item. This is often implemented by building additional caching into the client library, so that if a client moves to a replica node that contains old data, then the client library returns its cached value rather than the old value from the replica.</p>
+<p><em>Client-centric consistency models</em> are consistency models that involve the notion of a client or session in some way. For example, a client-centric consistency model might guarantee that a client will never see older versions of a data item. This is often implemented by building additional caching into the client library, so that if a client moves to a replica node that contains old data, then the client library returns its cached value rather than the old value from the replica.</p>
 <p>Clients may still see older versions of the data, if the replica node they are on does not contain the latest version, but they will never see anomalies where an older version of a value resurfaces (e.g. because they connected to a different replica). Note that there are many kinds of consistency models that are client-centric.</p>
 <h3>Eventual consistency</h3>
 <p>The <em>eventual consistency</em> model says that if you stop changing values, then after some undefined amount of time all replicas will agree on the same value. It is implied that before that time results between replicas are inconsistent in some undefined manner. Since it is <a href="http://www.bailis.org/blog/safety-and-liveness-eventual-consistency-is-not-safe/">trivially satisfiable</a> (liveness property only), it is useless without supplemental information.</p>

output/ebook.html

@@ -461,7 +461,7 @@ <h3>Strong consistency models</h3>
 <p>All the other consistency models have anomalies (compared to a system that guarantees strong consistency), because they behave in a way that is distinguishable from a non-replicated system. But often these anomalies are acceptable, either because we don&#39;t care about occasional issues or because we&#39;ve written code that deals with inconsistencies after they have occurred in some way.</p>
 <p>Note that there really aren&#39;t any universal typologies for weak consistency models, because &quot;not a strong consistency model&quot; (e.g. &quot;is distinguishable from a non-replicated system in some way&quot;) can be almost anything.</p>
 <h3>Client-centric consistency models</h3>
-<p><em>Client-centric consistency models</em> are consistency models which involve the notion of a client or session in some way. For example, a client-centric consistency model might guarantee that a client will never see older versions of a data item. This is often implemented by building additional caching into the client library, so that if a client moves to a replica node that contains old data, then the client library returns its cached value rather than the old value from the replica.</p>
+<p><em>Client-centric consistency models</em> are consistency models that involve the notion of a client or session in some way. For example, a client-centric consistency model might guarantee that a client will never see older versions of a data item. This is often implemented by building additional caching into the client library, so that if a client moves to a replica node that contains old data, then the client library returns its cached value rather than the old value from the replica.</p>
 <p>Clients may still see older versions of the data, if the replica node they are on does not contain the latest version, but they will never see anomalies where an older version of a value resurfaces (e.g. because they connected to a different replica). Note that there are many kinds of consistency models that are client-centric.</p>
 <h3>Eventual consistency</h3>
 <p>The <em>eventual consistency</em> model says that if you stop changing values, then after some undefined amount of time all replicas will agree on the same value. It is implied that before that time results between replicas are inconsistent in some undefined manner. Since it is <a href="http://www.bailis.org/blog/safety-and-liveness-eventual-consistency-is-not-safe/">trivially satisfiable</a> (liveness property only), it is useless without supplemental information.</p>

output/single-page.html

@@ -484,7 +484,7 @@ <h3>Strong consistency models</h3>
 <p>All the other consistency models have anomalies (compared to a system that guarantees strong consistency), because they behave in a way that is distinguishable from a non-replicated system. But often these anomalies are acceptable, either because we don&#39;t care about occasional issues or because we&#39;ve written code that deals with inconsistencies after they have occurred in some way.</p>
 <p>Note that there really aren&#39;t any universal typologies for weak consistency models, because &quot;not a strong consistency model&quot; (e.g. &quot;is distinguishable from a non-replicated system in some way&quot;) can be almost anything.</p>
 <h3>Client-centric consistency models</h3>
-<p><em>Client-centric consistency models</em> are consistency models which involve the notion of a client or session in some way. For example, a client-centric consistency model might guarantee that a client will never see older versions of a data item. This is often implemented by building additional caching into the client library, so that if a client moves to a replica node that contains old data, then the client library returns its cached value rather than the old value from the replica.</p>
+<p><em>Client-centric consistency models</em> are consistency models that involve the notion of a client or session in some way. For example, a client-centric consistency model might guarantee that a client will never see older versions of a data item. This is often implemented by building additional caching into the client library, so that if a client moves to a replica node that contains old data, then the client library returns its cached value rather than the old value from the replica.</p>
 <p>Clients may still see older versions of the data, if the replica node they are on does not contain the latest version, but they will never see anomalies where an older version of a value resurfaces (e.g. because they connected to a different replica). Note that there are many kinds of consistency models that are client-centric.</p>
 <h3>Eventual consistency</h3>
 <p>The <em>eventual consistency</em> model says that if you stop changing values, then after some undefined amount of time all replicas will agree on the same value. It is implied that before that time results between replicas are inconsistent in some undefined manner. Since it is <a href="http://www.bailis.org/blog/safety-and-liveness-eventual-consistency-is-not-safe/">trivially satisfiable</a> (liveness property only), it is useless without supplemental information.</p>