Dmitry Lomov (2014-05-02T09:57:19.000Z)
On Sun, Apr 21, 2013 at 6:55 PM, David Herman <dherman at mozilla.com> wrote:

> On Apr 20, 2013, at 9:21 PM, Mark S. Miller <erights at google.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Google Germany GmbH
*Dienerstr. 12, 80331 München., DE *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140502/d30dfe5e/attachment.html>
domenic at domenicdenicola.com (2014-05-07T20:49:03.343Z)
(Somehow missed this thread) Typed objects aka binary data should be on our
ES7 agenda as well.