2013/11/13 Mark S. Miller <erights at google.com>

> * Weak consistency (I know, people hear "CAP" and give up too much) won,
> which surprised some.
>
> Because Promises are asynchronous, even locally, the state of the world
> when a promise-based request is made differs from the one in which the
> request is received. Since partition induces rejection of all promises
> across that partition, connection recovery takes distinct paths through the
> code where one copes, in an application dependent manner, with having been
> out of communication.
>
> Further support for weak consistency should come at a higher level, e.g.,
> via the Unum model <
> https://www.cypherpunks.to/erights/talks/uni-tea/uni-tea.ppt>. Promises
> are a good substrate on which to build Una.
>

One of the most compelling approaches I've seen to date to enable eventual
consistency at a higher level is the recent work out of Microsoft Research
on cloud (data)types.
See <http://research.microsoft.com/apps/pubs/default.aspx?id=163842>. Tim
Coppieters, a student of mine, recently implemented the model as a pure JS
library, enabling easy replication of state among client and server
(node.js). His CloudTypes.js library is available at <
https://github.com/ticup/CloudTypes>. I'm pretty excited about the
elegance/simplicity of the model. The library is well-documented. Worth a
look for those into distributed systems.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131115/f5c7d3d7/attachment-0001.html>

2013/11/13 Mark S. Miller <erights at google.com>

>> * Weak consistency (I know, people hear "CAP" and give up too much) won,
> which surprised some.
>
> Because Promises are asynchronous, even locally, the state of the world
> when a promise-based request is made differs from the one in which the
> request is received. Since partition induces rejection of all promises
> across that partition, connection recovery takes distinct paths through the
> code where one copes, in an application dependent manner, with having been
> out of communication.
>
> Further support for weak consistency should come at a higher level, e.g.,
> via the [Unum model](https://www.cypherpunks.to/erights/talks/uni-tea/uni-tea.ppt). Promises
> are a good substrate on which to build Una.

One of the most compelling approaches I've seen to date to enable eventual
consistency at a higher level is the recent work out of Microsoft Research
on cloud (data)types.
See [Cloud Types for Eventual Consistency](http://research.microsoft.com/apps/pubs/default.aspx?id=163842). Tim Coppieters, a student of mine, recently implemented the model as a pure JS
library, enabling easy replication of state among client and server
(node.js). His CloudTypes.js library is available at https://github.com/ticup/CloudTypes. I'm pretty excited about the elegance/simplicity of the model. The library is well-documented. Worth a look for those into distributed systems.