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 *
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
