domenic at domenicdenicola.com (2013-11-17T18:00:18.346Z)
I mean the promises-unwrapping proposal that has now been accepted into ES6
and the DOM, and IIUC is being implemented by several browser makers. Let's
call these JS Promises. These descend from Promises/A+ which have a long
and complicated history, but the major branches of that history all to back
to E. Approximately:
```
JS Promises from Promises/A+ from merge(Promises/A, Q)
Promises/A from Dojo Deferred from MochiKit Deferred from Twisted
Python Deferred from E Promises.
Q from Promises/C from Waterken Q from E Promises
```
My point is that the differences between hard references and JS Promises
are exactly the non-transparencies needed to address your non-Stonebreaker
bullets:
> * One cannot ignore network latency and partitioning.
Latency:
JS Promises are asynchronous and were carefully designed to not preclude
future promise pipelining. Q makes use of this pipelining.
Partition:
JS Promises have a terminal "rejected" state indicating that they will
never designate any object. This descends directly from the E "broken"
state, where it was was also used to make network partition apparent in a
fail-stop manner. Q makes use of this.
> * Sync RPC is the wrong model (it already yielded to async calls,
futures/promises, and the like).
Exactly!
> * 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.
I mean the promises-unwrapping proposal that has now been accepted into ES6 and the DOM, and IIUC is being implemented by several browser makers. Let's call these JS Promises. These descend from Promises/A+ which have a long and complicated history, but the major branches of that history all to back to E. Approximately: JS Promises from Promises/A+ from merge(Promises/A, Q) Promises/A from Dojo Deferred from MochiKit Deferred from Twisted Python Deferred from E Promises. Q from Promises/C from Waterken Q from E Promises My point is that the differences between hard references and JS Promises are exactly the non-transparencies needed to address your non-Stonebreaker bullets: * One cannot ignore network latency and partitioning. Latency: JS Promises are asynchronous and were carefully designed to not preclude future promise pipelining. Q makes use of this pipelining. Partition: JS Promises have a terminal "rejected" state indicating that they will never designate any object. This descends directly from the E "broken" state, where it was was also used to make network partition apparent in a fail-stop manner. Q makes use of this. * Sync RPC is the wrong model (it already yielded to async calls, futures/promises, and the like). Exactly! * 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. On Tue, Nov 12, 2013 at 3:57 PM, Brendan Eich <brendan at mozilla.com> wrote: > Mark S. Miller wrote: > >> Link please for the Stonebreaker point? >> > > Sorry, having a hard time finding it now. It was about the longer history > since SQL was pioneered; also about NoSQL. > > > On your other bullets, you're preaching to the choir. These are exactly >> the considerations that led to the E promise design, now adopted by JS. >> >> http://www.erights.org/elib/concurrency/semi-transparent.html >> >> Where it says "<-", substitute "!". >> >> In addition, promise pipelining gives us a huge win over network latency >> beyond the points made on that page. >> > > Fair point. > > > Now that we've adopted such promises, we've paid the anti-transparency >> costs of good distributed objects. This was quite intentional. Now that >> we've paid the costs, we may as well collect the benefits. >> > > I think your use of "we" and past tense here are not shared as widely as > you'd like. Anything deployed on the public web yet? > > /be > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131112/a7721b6c/attachment-0001.html>