Indeed. Thanks for reviving this thread. Altogether, I'm pleasantly surprised how well this old thread holds up in light of more recent events.
On Fri, May 2, 2014 at 2:57 AM, Dmitry Lomov <[email protected]> wrote: > > > > On Sun, Apr 21, 2013 at 6:55 PM, David Herman <[email protected]> wrote: > >> On Apr 20, 2013, at 9:21 PM, Mark S. Miller <[email protected]> wrote: >> >> > * Communicating Event Loop concurrency model, >> > - with the two-priority event loop already required by both >> browser and server. >> > * Object.observe >> > * Distribution compatible promises (at least Promises/A+) >> > * Module Loaders >> > * Weak References >> >> Thanks, Mark, for getting a good discussion going here. >> >> I agree with Sam that we need loaders and at least a minimal event loop >> model in ES6. As we discussed in the last meeting, we have our work to do >> but I believe we're on track. >> >> I think the more important part of this conversation is the priority >> list, rather than nailing down exactly what has to land in what version of >> the spec. While the spec process has enough constant-factor overhead that >> spec releases themselves must be monolithic, I believe we've done a good >> job over the last few years moving to a more modular model (Einstein might >> call it "as modular as possible but no modularer," if he were as bad at >> English as I am). I think the ES6 process has worked well so far, setting >> time-based goal-posts for the spec but deciding on a feature-by-feature >> basis whether they make the cutoff. Of course, features interact, so they >> have to be designed with others in mind and sometimes they may have to land >> or be deferred in groups. >> >> I agree that promises, Object.observe, and weak references are next up on >> the scale of being high enough priority and well-baked enough. I also agree >> with Domenic that value types deserve to be on this list, including >> integers as well as float32. >> > > (Somehow missed this thread) Typed objects aka binary data should be on > our ES7 agenda as well. > > Dmitry > >> >> > Elements of the concurrency theme that may be in ES7 or may be >> postponed to ES8: >> > >> > * RiverTrail >> > * The Vat model >> > * The semantics of inter-vat communications >> > - including a principled alternative of structured clone >> > - The emphasis being remote object messages, with postMessage >> > and such being only one of many transports. >> > * The promise hooks needed to extend promises securely over the >> network >> > - See makeFar and makeRemote at >> > >> https://code.google.com/p/es-lab/source/browse/trunk/src/ses/makeQ.js#410 >> > * Event streams >> >> Agreed, although have some reservations about vats (and I'm just >> generally confused about how they relate to / differ from / interact with >> workers -- but that's for another thread; no pun intended). We may in fact >> want to consider pulling workers and structured clone into ES7/ES8, in the >> tradition of embracing pure computational features of JS that are currently >> only standardized in the DOM. It would also give us an opportunity to see >> if we could refine structured clone. >> >> > Some things that I think should clearly wait till ES8: >> > >> > * SES >> > * Distributed persistence >> > * The actual distributed cryptographic protocol for doing distributed >> secure persistent object communications. >> >> Agreed. >> >> > Some of these should perhaps be on separate tracks within TC39, much as >> i18n is already on a separate track. >> >> Makes sense to me! >> >> Dave >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > > > -- > Google Germany GmbH > *Dienerstr. 12, 80331 München., DE * > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
