Intent to Implement: DOM Futures

1,815 views
Skip to first unread message

Takeshi Yoshino

unread,
May 23, 2013, 12:28:03 PM5/23/13
to blink-dev, Kenji Baheux

Primary eng/PM emails

Eng tyos...@chromium.org, PM kenji...@chromium.org


Spec

WHATWG DOM Standard http://dom.spec.whatwg.org/#futures


Summary

Futures provide a convenient way to get access to the result of an operation that may have already occurred or may happen in the future.


Futures can be returned by platform APIs, but can also be used in conjunction with an existing API to make it easier to work with. See the examples on the spec and Alex’s old doc https://github.com/slightlyoff/Futures.


Motivation

Allow asynchronous processing code to represent data dependency in more readable form. Planned to be applied to Streams, XMLHttpRequest, File/Blob, etc.


We are seeking for a new better I/O API. Some people on the spec discussion list suggested that we should tryout DOM Futures to implement streaming access API for XMLHttpRequest's result and request body. See also the Blink review thread for Streams API [1]


Compatibility Risk

None. To be implemented behind a runtime flag. There’s still active discussion on the Futures spec at public-...@w3.org.


Ongoing technical constraints

None


Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes


OWP launch tracking bug?

crbug.com/243345


Row on feature dashboard?

Yes


Requesting approval to ship?

No


Dimitri Glazkov

unread,
May 23, 2013, 12:29:18 PM5/23/13
to Takeshi Yoshino, blink-dev, Kenji Baheux
LGTM. Futures are the future.

Harald Alvestrand

unread,
May 24, 2013, 4:33:22 AM5/24/13
to Dimitri Glazkov, Takeshi Yoshino, blink-dev, Kenji Baheux
 Good to see someone committing to coding this!

Question on schedule: The bug is marked m30 - how certain are you of this? As out of:

- Probably not M29, definitely M30
- Definitely not M29, definitely M30
- Probably M30, definitely M31
.... you can tell where this is going ....

The W3C WebRTC WG has a telechat next week to discuss futures, and the more information we have on when it'll be in Chrome, the better we'll be able to figure out when it makes sense to depend on them.

Takeshi Yoshino

unread,
May 24, 2013, 8:12:35 PM5/24/13
to Harald Alvestrand, Dimitri Glazkov, blink-dev, Kenji Baheux
On Fri, May 24, 2013 at 5:33 PM, Harald Alvestrand <h...@google.com> wrote:
 Good to see someone committing to coding this!

Question on schedule: The bug is marked m30 - how certain are you of this? As out of:

- Probably not M29, definitely M30
- Definitely not M29, definitely M30
- Probably M30, definitely M31
.... you can tell where this is going ....

I've roughly implemented it this week. resolver.accept, reject and new Future(), Future.accept, reject are working.

Basically I think we don't need so much time. Regarding behind-flag schedule, my estimation is "Probably not M29, definitely M30".

I received some redesign suggestion from abarth@. I'll try that next week.

Kenneth Rohde Christiansen

unread,
May 25, 2013, 12:31:22 PM5/25/13
to Takeshi Yoshino, Harald Alvestrand, Dimitri Glazkov, blink-dev, Kenji Baheux
LGTM! Great to see this added!
--
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4294 9458 / E-mail kenneth at webkit.org

﹆﹆﹆

Tab Atkins Jr.

unread,
May 29, 2013, 1:43:27 PM5/29/13
to Takeshi Yoshino, Harald Alvestrand, Dimitri Glazkov, blink-dev, Kenji Baheux
On Fri, May 24, 2013 at 5:12 PM, Takeshi Yoshino <tyos...@google.com> wrote:
> On Fri, May 24, 2013 at 5:33 PM, Harald Alvestrand <h...@google.com> wrote:
>>
>> Good to see someone committing to coding this!
>>
>> Question on schedule: The bug is marked m30 - how certain are you of this?
>> As out of:
>>
>> - Probably not M29, definitely M30
>> - Definitely not M29, definitely M30
>> - Probably M30, definitely M31
>> .... you can tell where this is going ....
>
>
> I've roughly implemented it this week. resolver.accept, reject and new
> Future(), Future.accept, reject are working.
>
> Basically I think we don't need so much time. Regarding behind-flag
> schedule, my estimation is "Probably not M29, definitely M30".
>
> I received some redesign suggestion from abarth@. I'll try that next week.

Thanks so much for this!

Note that there's likely to be a tiny bit of churn in the API in the
very near future (next week or two), though it should be mostly
invisible to authors, just some minor details of how .then() works and
a new method added (provisionally called .chain(), but that may be
changed).

~TJ

Yutaka Hirano

unread,
May 30, 2013, 2:11:52 AM5/30/13
to Tab Atkins Jr., Adam Barth, Takeshi Yoshino, Harald Alvestrand, Dimitri Glazkov, blink-dev, Kenji Baheux
Hi, I'm going to implement this (agreed with Takeshi).
I prefer implementing it in JavaScript, as suggested by you.
Currently I'm wondering the comment at http://crrev.com/15786003/
  Using ScriptValue is going to lead to many memory leaks.
Adam, is there any document or code explaining how to hold an arbitrary JS object?
I thought using ScriptValue to hold a JS object was allowed, like CustomeEvent[1].

Thanks,

Adam Barth

unread,
May 30, 2013, 2:26:40 AM5/30/13
to Yutaka Hirano, Tab Atkins Jr., Takeshi Yoshino, Harald Alvestrand, Dimitri Glazkov, blink-dev, Kenji Baheux
On Wed, May 29, 2013 at 11:11 PM, Yutaka Hirano <yhi...@chromium.org> wrote:
Hi, I'm going to implement this (agreed with Takeshi).
I prefer implementing it in JavaScript, as suggested by you.
Currently I'm wondering the comment at http://crrev.com/15786003/
  Using ScriptValue is going to lead to many memory leaks.
Adam, is there any document or code explaining how to hold an arbitrary JS object?

There isn't, but you can ask haraken or some of the other folks who work on the bindings often in TOK for advice.
 
I thought using ScriptValue to hold a JS object was allowed, like CustomeEvent[1].

CustomEvent leaks memory.  :(

var e = new CustomEvent({});
e.initCustomEvent("foo", false, false, e);

Now the CustomEvent C++ object behind e is holding e as a ScriptValue, which is a cycle and hence a leak.  Terrible things happen if the ScriptValue ends up retaining a function because that function can retain many objects in its closure.

For Futures, you're going to be dealing with lots of objects that hold references to functions, which increases the likelihood of a leaks.  That's why I'd recommend trying to implement as much of the machinery in JavaScript as possible.  That way the garbage collector can understand all the links between the objects and collect cycles.

Adam

Yutaka Hirano

unread,
May 30, 2013, 2:50:30 AM5/30/13
to Adam Barth, Tab Atkins Jr., Takeshi Yoshino, Harald Alvestrand, Dimitri Glazkov, blink-dev, Kenji Baheux
Thank you for the advice, I will investigate.

Yutaka Hirano

unread,
Jun 10, 2013, 3:04:47 AM6/10/13
to Takeshi Yoshino, blink-dev, Kenji Baheux
As described at http://infrequently.org/2013/06/sfuturepromiseg/ , Future is renamed to Promise.
Moreover, it will be included in the future ECMAScript standard as well.
We are planning to implement it in V8, not in Blink.

Greg Simon

unread,
Jun 10, 2013, 12:31:49 PM6/10/13
to Yutaka Hirano, Takeshi Yoshino, blink-dev, Kenji Baheux, Daniel Clifford
Mozilla is working on a patch right now:

Aaron Boodman

unread,
Jun 10, 2013, 1:30:23 PM6/10/13
to Adam Barth, Yutaka Hirano, Tab Atkins Jr., Takeshi Yoshino, Harald Alvestrand, Dimitri Glazkov, blink-dev, Kenji Baheux
On Wed, May 29, 2013 at 11:26 PM, Adam Barth <aba...@chromium.org> wrote:
On Wed, May 29, 2013 at 11:11 PM, Yutaka Hirano <yhi...@chromium.org> wrote:
Hi, I'm going to implement this (agreed with Takeshi).
I prefer implementing it in JavaScript, as suggested by you.
Currently I'm wondering the comment at http://crrev.com/15786003/
  Using ScriptValue is going to lead to many memory leaks.
Adam, is there any document or code explaining how to hold an arbitrary JS object?

There isn't, but you can ask haraken or some of the other folks who work on the bindings often in TOK for advice.

Is this the first time we've ever used JavaScript to implement bindings?

The reason I ask is that the language boundary between JS and C++ typically provides some isolation that I worry about us losing.

* Will people be accidentally or maliciously get access to the bindings implementation and confuse it? Remember that JavaScript has constructs like arugments.callee that allow you to walk the call stack and get access to data that wouldn't necessarily be obvious when reading the code.

* Will there be unintended interactions between JavaScript in the page and JavaScript in the bindings implementation - for example, collisions on global objects (modifying Array.prototype and so-on?).

* When an exception is raised by C++ code typically, it shows up to JavaScript as occurring at the deepest JS frame before we went into C++. If we implement Promises in JS, will we lose this and end up with exceptions being sourced at some point inside the Promises implementation?

- a

Erik Arvidsson

unread,
Jun 10, 2013, 8:07:40 PM6/10/13
to Aaron Boodman, Adam Barth, Yutaka Hirano, Tab Atkins Jr., Takeshi Yoshino, Harald Alvestrand, Dimitri Glazkov, blink-dev, Kenji Baheux
On Mon, Jun 10, 2013 at 1:30 PM, Aaron Boodman <a...@chromium.org> wrote:
On Wed, May 29, 2013 at 11:26 PM, Adam Barth <aba...@chromium.org> wrote:
On Wed, May 29, 2013 at 11:11 PM, Yutaka Hirano <yhi...@chromium.org> wrote:
Hi, I'm going to implement this (agreed with Takeshi).
I prefer implementing it in JavaScript, as suggested by you.
Currently I'm wondering the comment at http://crrev.com/15786003/
  Using ScriptValue is going to lead to many memory leaks.
Adam, is there any document or code explaining how to hold an arbitrary JS object?

There isn't, but you can ask haraken or some of the other folks who work on the bindings often in TOK for advice.

Is this the first time we've ever used JavaScript to implement bindings?

The reason I ask is that the language boundary between JS and C++ typically provides some isolation that I worry about us losing.

* Will people be accidentally or maliciously get access to the bindings implementation and confuse it? Remember that JavaScript has constructs like arugments.callee that allow you to walk the call stack and get access to data that wouldn't necessarily be obvious when reading the code.

"use strict" to remove arguments.callee. 

* Will there be unintended interactions between JavaScript in the page and JavaScript in the bindings implementation - for example, collisions on global objects (modifying Array.prototype and so-on?).

Just how V8's standard library is written in JS we need to be careful and not use these. We must only use the original functions.

* When an exception is raised by C++ code typically, it shows up to JavaScript as occurring at the deepest JS frame before we went into C++. If we implement Promises in JS, will we lose this and end up with exceptions being sourced at some point inside the Promises implementation?

Doesn't V8 extension already handle this? If I use Intl I cannot step into its functions.

--
erik


Aaron Boodman

unread,
Jun 10, 2013, 8:52:29 PM6/10/13
to Erik Arvidsson, Adam Barth, Yutaka Hirano, Tab Atkins Jr., Takeshi Yoshino, Harald Alvestrand, Dimitri Glazkov, blink-dev, Kenji Baheux
On Mon, Jun 10, 2013 at 5:07 PM, Erik Arvidsson <a...@chromium.org> wrote:
On Mon, Jun 10, 2013 at 1:30 PM, Aaron Boodman <a...@chromium.org> wrote:
On Wed, May 29, 2013 at 11:26 PM, Adam Barth <aba...@chromium.org> wrote:
On Wed, May 29, 2013 at 11:11 PM, Yutaka Hirano <yhi...@chromium.org> wrote:
Hi, I'm going to implement this (agreed with Takeshi).
I prefer implementing it in JavaScript, as suggested by you.
Currently I'm wondering the comment at http://crrev.com/15786003/
  Using ScriptValue is going to lead to many memory leaks.
Adam, is there any document or code explaining how to hold an arbitrary JS object?

There isn't, but you can ask haraken or some of the other folks who work on the bindings often in TOK for advice.

Is this the first time we've ever used JavaScript to implement bindings?

The reason I ask is that the language boundary between JS and C++ typically provides some isolation that I worry about us losing.

* Will people be accidentally or maliciously get access to the bindings implementation and confuse it? Remember that JavaScript has constructs like arugments.callee that allow you to walk the call stack and get access to data that wouldn't necessarily be obvious when reading the code.

"use strict" to remove arguments.callee.

OK.
  
* Will there be unintended interactions between JavaScript in the page and JavaScript in the bindings implementation - for example, collisions on global objects (modifying Array.prototype and so-on?).

Just how V8's standard library is written in JS we need to be careful and not use these. We must only use the original functions.

This seems like a pretty easy mistake to make, and hard to notice in review. I guess the v8 team gets along OK, but I am concerned about relying on anyone writing bindings in Blink to think carefully every time they use a member of Array, String, Object, etc.

* When an exception is raised by C++ code typically, it shows up to JavaScript as occurring at the deepest JS frame before we went into C++. If we implement Promises in JS, will we lose this and end up with exceptions being sourced at some point inside the Promises implementation?

Doesn't V8 extension already handle this? If I use Intl I cannot step into its functions.

I'm not sure, it may have been fixed. The last I saw, you could not step into such functions but you'd still get exceptions that said they were from deep inside the v8 extension.

===

The other related issue is that with IDL the type-checking for parameters is automated, so you get consistent error handling across the platform. I have worked on some systems that did not have this, and it was very difficult to keep the parameter validation behavior consistent across APIs.

I wonder if it is possible to combine the best elements of the two approaches. Something like: interfaces continue to be declared in WebIDL, but are implemented in JS. The bidings run in a separate, isolated context with its own globals. Perhaps this context could be shared across all frames in an origin to reduce cost.

When user code calls a platform function, two things happen: (1) the parameters are validated as per the IDL automatically, and (2) each parameter is wrapped in a thin proxy before being passed onto the bindings implementation. The proxy isolates the platform JS from the user JS, so that when one side calls, e.g., "substr" on a String object, the real String.prototype.substr gets called on the object on the other side.

- a

Benjamin Kalman

unread,
Jun 11, 2013, 12:59:15 PM6/11/13
to blin...@chromium.org, Kenji Baheux, tyos...@google.com
I fear I am perpetuating a slightly off-topic discussion here, so maybe we should move this, but anyhow:

Some data points for isolated JS problems - we're having all of these issues with extension bindings at the moment, now that we're (a) running them in all web pages, and (b) loading them lazily (i.e. after all the user JS has run). It's still not resolved, there are several issues to iron out in the next week.

Some background: https://code.google.com/p/chromium/issues/detail?id=72992 (though I've fixed at least 5 distinct bugs in the last month relating to issues like this).

That bug become about potentially building something into the v8 API to help with this, but the answer (and fair enough) is that given extensions would be the only customer for this, it's not something v8 need worry about. We *can* do it ourselves.

And that answer will probably involve running a small amount of JS up-front to save references, like v8 does and has been discussed here (rather than trying to do something fancy in a new context). However, if blink folks will need to do something similar, I feel like it *is* something we should consider exposing from v8 in some way. Not necessarily the complex things in that bug, but just the $Function, $Object things, for efficiency and simplicity purposes (that v8 stuff is compiled in afaik so it's basically free, unlike running our own v8::Extensions):


Likewise, we could consider creating an easy way to create a poisoned context, which v8 testing presumably does, to make sure all the code works and continues to work.

Aaron Boodman

unread,
Jun 11, 2013, 1:08:04 PM6/11/13
to Benjamin Kalman, blink-dev, Kenji Baheux, Takeshi Yoshino
On Tue, Jun 11, 2013 at 9:59 AM, Benjamin Kalman <kal...@chromium.org> wrote:
Some background: https://code.google.com/p/chromium/issues/detail?id=72992 (though I've fixed at least 5 distinct bugs in the last month relating to issues like this).

I think you pasted the wrong bug.
 
- a

Benjamin Kalman

unread,
Jun 11, 2013, 1:19:24 PM6/11/13
to Aaron Boodman, blink-dev, Kenji Baheux, Takeshi Yoshino

Adam Barth

unread,
Jun 11, 2013, 2:12:40 PM6/11/13
to Benjamin Kalman, Aaron Boodman, blink-dev, Kenji Baheux, Takeshi Yoshino
I'm not sure I fully understood your message, but running JavaScript in a web page after that page has had a chance to change the global object is very tricky and needs to be done carefully.  I don't think there are likely to be any quick fixes in that regard.

Adam

Erik Arvidsson

unread,
Jun 11, 2013, 2:17:01 PM6/11/13
to Adam Barth, Benjamin Kalman, Aaron Boodman, blink-dev, Kenji Baheux, Takeshi Yoshino
On Tue, Jun 11, 2013 at 2:12 PM, Adam Barth <aba...@chromium.org> wrote:
I'm not sure I fully understood your message, but running JavaScript in a web page after that page has had a chance to change the global object is very tricky and needs to be done carefully.  I don't think there are likely to be any quick fixes in that regard.

Ben,

Like Danno suggests, you need to store all the builtins ahead of any possible user code and then be very careful to apply OCAP style programming. The alternative is to use an isolated world but I assume that is out of the question for other reasons.
 
On Tue, Jun 11, 2013 at 10:19 AM, Benjamin Kalman <kal...@chromium.org> wrote:


On Tue, Jun 11, 2013 at 10:08 AM, Aaron Boodman <a...@chromium.org> wrote:
On Tue, Jun 11, 2013 at 9:59 AM, Benjamin Kalman <kal...@chromium.org> wrote:
Some background: https://code.google.com/p/chromium/issues/detail?id=72992 (though I've fixed at least 5 distinct bugs in the last month relating to issues like this).

I think you pasted the wrong bug.
 
- a





--
erik


Benjamin Kalman

unread,
Jun 11, 2013, 2:21:21 PM6/11/13
to Erik Arvidsson, Adam Barth, Aaron Boodman, blink-dev, Kenji Baheux, Takeshi Yoshino
Yes, storing the necessary functions ahead of time is what I'm resigned to doing. I'm just worried that if we do it + blink needs to do it then that's a couple of extra scripts to run on context startup, and scripts aren't free to run - which is why it may be better for v8 to expose those clean methods. That, and it'd be more convenient and just less code.

(and then as I said, furthermore a way to create whatever diabolical setup that v8 tests with to make sure their code runs properly).

I don't know what "OCAP style" means.

Adam Barth

unread,
Jun 11, 2013, 2:25:06 PM6/11/13
to Benjamin Kalman, Erik Arvidsson, Aaron Boodman, blink-dev, Kenji Baheux, Takeshi Yoshino
On Tue, Jun 11, 2013 at 11:21 AM, Benjamin Kalman <kal...@chromium.org> wrote:
Yes, storing the necessary functions ahead of time is what I'm resigned to doing. I'm just worried that if we do it + blink needs to do it then that's a couple of extra scripts to run on context startup, and scripts aren't free to run - which is why it may be better for v8 to expose those clean methods. That, and it'd be more convenient and just less code.

(and then as I said, furthermore a way to create whatever diabolical setup that v8 tests with to make sure their code runs properly).

In the long term, I think it would be good to unify the machinery for the DOM bindings and the extension bindings.  It seems a bit silly to have two separate systems for creating JavaScript bindings.  It leads to lots of duplication, like the kind you describe.
 
I don't know what "OCAP style" means.

OCAP means "object-capability".  In particular, you have to be careful not to leak references to any of your objects to the page, and, conversely, you have to be careful not to touch objects from the page except in very controlled idioms.  It requires very careful coding practices in JavaScript.

Adam

Benjamin Kalman

unread,
Jun 11, 2013, 2:30:44 PM6/11/13
to Adam Barth, Erik Arvidsson, Aaron Boodman, blink-dev, Kenji Baheux, Takeshi Yoshino, Ankur Taly

On Tue, Jun 11, 2013 at 11:25 AM, Adam Barth <aba...@chromium.org> wrote:
In the long term, I think it would be good to unify the machinery for the DOM bindings and the extension bindings.  It seems a bit silly to have two separate systems for creating JavaScript bindings.  It leads to lots of duplication, like the kind you describe.

I absolutely agree, and have been giving it thought lately, but this is certainly off topic. Perhaps that is the answer in the long term. Short term it'll be interesting to see what the perf bots have to say about the up-front v8::Extension, if anything.

OCAP - thanks. I think that ataly@ might even have a tool which figures that out somehow.

Alec Flett

unread,
Jun 11, 2013, 5:07:12 PM6/11/13
to Adam Barth, Benjamin Kalman, Erik Arvidsson, Aaron Boodman, blink-dev, Kenji Baheux, Takeshi Yoshino
On Tue, Jun 11, 2013 at 11:25 AM, Adam Barth <aba...@chromium.org> wrote:
 
I don't know what "OCAP style" means.

OCAP means "object-capability".  In particular, you have to be careful not to leak references to any of your objects to the page, and, conversely, you have to be careful not to touch objects from the page except in very controlled idioms.  It requires very careful coding practices in JavaScript.


It seems like there are likely some JS patterns that can help look for this in a testing context - i.e. annotating private objects, importing the script, and then walking all objects in the global scope - not something that would be done during pageload, but something that could be done to "bless" a script at build time. there are of course all sorts of ways to purposefully code around that but it might be a nice sanity check. 

Another related, alternative is work that the Caja project has done - a lot of research in to making scripts "safe" in a more global context - this could be another way that js-based impl could get exposed, providing the equivalent of some of the automated checks that our bindings code has now.

Alec

Yutaka Hirano

unread,
Jun 11, 2013, 9:17:49 PM6/11/13
to Alec Flett, Adam Barth, Benjamin Kalman, Erik Arvidsson, Aaron Boodman, blink-dev, Kenji Baheux, Takeshi Yoshino
On Tue, Jun 11, 2013 at 11:25 AM, Adam Barth <aba...@chromium.org> wrote:
 
I don't know what "OCAP style" means.

OCAP means "object-capability".  In particular, you have to be careful not to leak references to any of your objects to the page, and, conversely, you have to be careful not to touch objects from the page except in very controlled idioms.  It requires very careful coding practices in JavaScript.


Must I solve this issue at the first CL?
I would like to submit a CL that passes layout tests, and fix issues like this later (Promise will be hidden by a runtime flag).

Adam Barth

unread,
Jun 11, 2013, 9:27:06 PM6/11/13
to Yutaka Hirano, Alec Flett, Adam Barth, Benjamin Kalman, Erik Arvidsson, Aaron Boodman, blink-dev, Kenji Baheux, Takeshi Yoshino


On Tuesday, June 11, 2013, Yutaka Hirano <yhi...@google.com> wrote:
> On Tue, Jun 11, 2013 at 11:25 AM, Adam Barth <aba...@chromium.org> wrote:
>>
>>  
>>>
>>> I don't know what "OCAP style" means.
>>
>> OCAP means "object-capability".  In particular, you have to be careful not to leak references to any of your objects to the page, and, conversely, you have to be careful not to touch objects from the page except in very controlled idioms.  It requires very careful coding practices in JavaScript.
>
> Must I solve this issue at the first CL?
> I would like to submit a CL that passes layout tests, and fix issues like this later (Promise will be hidden by a runtime flag).

We can build the feature incrementally behind the flag.  We'll need to solve it before removing the flag, of course.  :)

Adam

Yutaka Hirano

unread,
Jul 10, 2013, 12:05:11 AM7/10/13
to Adam Barth, Alec Flett, Benjamin Kalman, Erik Arvidsson, Aaron Boodman, blink-dev, Kenji Baheux, Takeshi Yoshino
DOM/Promises is implemented in Blink.
It is working now behind "Promise" experimental runtime flag.

I am going to find the spec of ProgressPromise and implement it.

Kenji Baheux

unread,
Jul 10, 2013, 12:19:17 AM7/10/13
to Yutaka Hirano, Adam Barth, Alec Flett, Benjamin Kalman, Erik Arvidsson, Aaron Boodman, blink-dev, Takeshi Yoshino
Congratulations on the progress so far!

About the "Promise" experimental flag: any reason why you could not just use the existing "Enable experimental WebKit (*cough*... ^ ^; ) features" flag? I believe it's the standard practice.


2013/7/10 Yutaka Hirano <yhi...@google.com>

Yutaka Hirano

unread,
Jul 10, 2013, 12:46:03 AM7/10/13
to Kenji Baheux, Adam Barth, Alec Flett, Benjamin Kalman, Erik Arvidsson, Aaron Boodman, blink-dev, Takeshi Yoshino
Sorry for the confusion, the flag is a runtime enabled flag in Blink.
Runtime enabled flags whose status is "experimental" are enabled if "Enable experimental WebKit features" chrome flag is enabled.
So you can enable DOM/Promises by enabling "Enable experimental WebKit features" in chrome://flags.

Kenji Baheux

unread,
Jul 10, 2013, 12:53:48 AM7/10/13
to Yutaka Hirano, Adam Barth, Alec Flett, Benjamin Kalman, Erik Arvidsson, Aaron Boodman, blink-dev, Takeshi Yoshino
Gotcha!


2013/7/10 Yutaka Hirano <yhi...@google.com>

Adam Barth

unread,
Jul 10, 2013, 1:01:53 AM7/10/13
to Kenji Baheux, Yutaka Hirano, Alec Flett, Benjamin Kalman, Erik Arvidsson, Aaron Boodman, blink-dev, Takeshi Yoshino
On Tue, Jul 9, 2013 at 9:19 PM, Kenji Baheux <kenji...@chromium.org> wrote:
Congratulations on the progress so far!

About the "Promise" experimental flag: any reason why you could not just use the existing "Enable experimental WebKit (*cough*... ^ ^; ) features" flag? I believe it's the standard practice.

^^^ Anyone want to rename this flag to "Enable experimental web features" ?  :)

Adam

Mike West

unread,
Jul 10, 2013, 1:10:00 AM7/10/13
to Adam Barth, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Kenji Baheux, Takeshi Yoshino

I have a CL up for that rename that I thought landed already: https://codereview.chromium.org/14940009/

I'll rebaseline it this morning. :)

-mike

yusuke...@google.com

unread,
Aug 20, 2013, 4:06:40 AM8/20/13
to blin...@chromium.org, Adam Barth, Yutaka Hirano, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Kenji Baheux, Takeshi Yoshino
DOM Promises redesign to allow deriving subclasses

Since the Promises implementation in Blink is composed of JavaScript objects, we cannot create subclasses of the Promies type in IDL and cannot use the Promise type in IDL.
To make the Promise type subclass-friendly, we redesign the Promises implementation in Blink[1].
This design introduces Promise native objects. It provides the Promise type to IDL and makes inheriting Promise interface possible. 

Please let me know if you have any comments.

[1] https://docs.google.com/document/d/1ioAhI9ggEKFG8SNY1yOQcgOWuzSs_4CCKQWVf8Gbl3k/edit?usp=sharing

Adam Barth

unread,
Aug 20, 2013, 4:10:32 AM8/20/13
to yusuke...@google.com, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Kenji Baheux, Takeshi Yoshino
WebCrypto doesn't need subclassing anymore.  Are we sure we want to support subclassing Promise?

Adam

Yutaka Hirano

unread,
Aug 20, 2013, 4:11:22 AM8/20/13
to Yusuke Suzuki, blink-dev, Adam Barth, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Kenji Baheux, Takeshi Yoshino

Yutaka Hirano

unread,
Aug 20, 2013, 4:15:57 AM8/20/13
to Yusuke Suzuki, blink-dev, Adam Barth, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Kenji Baheux, Takeshi Yoshino
Sorry, I missent an empty message.

"Proposed Design" section describes the current design and "Subclass Promise" describes the new one.
We are planning to re-implement DOM/Promises in the latter way.

Kenneth Rohde Christiansen

unread,
Aug 20, 2013, 4:18:14 AM8/20/13
to Adam Barth, yusuke...@google.com, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Kenji Baheux, Takeshi Yoshino
I think some SysApps specs intent to do that.

Kenneth
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.



--
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone +45 4294 9458 / E-mail kenneth at webkit.org

﹆﹆﹆
Message has been deleted

Adam Barth

unread,
Aug 20, 2013, 4:22:38 AM8/20/13
to Kenneth Rohde Christiansen, yusuke...@google.com, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Kenji Baheux, Takeshi Yoshino
On Tue, Aug 20, 2013 at 1:18 AM, Kenneth Rohde Christiansen <kenneth.ch...@gmail.com> wrote:
I think some SysApps specs intent to do that.

Do you have some examples?  It's not clear to me whether Promises should be treated as a JavaScript primitive like Function and Date or like a DOM object, like EventTarget.

My sense is that Promises are relatively new and we should be conservative in how we use them for a while so that we can learn what works well and what doesn't work well.
Message has been deleted

Yusuke Suzuki

unread,
Aug 20, 2013, 4:45:42 AM8/20/13
to blin...@chromium.org, Kenneth Rohde Christiansen, yusuke...@google.com, Yutaka Hirano, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Kenji Baheux, Takeshi Yoshino, aba...@chromium.org
Oops, sorry, I've misconfigured my account.

WebCrypto doesn't need subclassing anymore.  Are we sure we want to support subclassing Promise?

ProgressPromise and AbortablePromise (AbortableProgressPromise) need support for subclassing Promise.

ProgressPromise is still controversial[1]. But if ProgressPromise is discarded and "an object that implements both `Promise` and `EventTarget` interfaces" design is chosen, it also becomes the subclass of the Promise type.


On Tue, Aug 20, 2013 at 5:31 PM, <yusuke...@google.com> wrote:
Oops, sorry, I've misdeleted my message in this thread.

WebCrypto doesn't need subclassing anymore.  Are we sure we want to support subclassing Promise?

ProgressPromise and AbortablePromise (AbortableProgressPromise) need support for subclassing Promise.

ProgressPromise is still controversial[1]. But if ProgressPromise is discarded and "an object that implements both `Promise` and `EventTarget` interfaces" design is chosen, it also becomes the subclass of the Promise type.

Kenneth Rohde Christiansen

unread,
Aug 20, 2013, 4:54:10 AM8/20/13
to Adam Barth, yusuke...@google.com, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Kenji Baheux, Takeshi Yoshino
Yes, http://runtime.sysapps.org/#idl-def-DownloadRequest (it hasn't
need renamed to Promise yet though, but this would be a
DownloadPromise I suppose)

Cheers
Kenneth

Adam Barth

unread,
Aug 20, 2013, 5:01:06 AM8/20/13
to Yusuke Suzuki, blink-dev, Kenneth Rohde Christiansen, yusuke...@google.com, Yutaka Hirano, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Kenji Baheux, Takeshi Yoshino
The design in your doc looks pretty reasonable.  I hope we can do better than ProtectedUntilNextTask, but we can iterate on that part in code review.  Here's a CL that sketches out a different approach to a related problem:


That CL introduces the notion of a GarbageCollected object, which clients interact with via v8::Handles.  Instead of using something like ProtectedUntilNextTask, v8::Handles are naturally protected until the v8::HandleScope goes out of scope.  I wonder if we could use a similar approach here.

The main concern I had about the use of Promise subclasses in WebCrypto was that we could get into a situation where we'd created a Promise, but we were waiting for script to do something before the Promise resolves (e.g., feed more data into the encryption function).  If the script never does that thing, we would have ended up retaining the ScriptPromiseResolver and hence leaked memory.

Whenever we create Promise objects, we need to be sure that they will eventually resolve or else we'll leak memory.  That's not directly related to subclassing Promises, but it's connected in that features that want to subclass Promises seem to also want to use them in less deterministic ways.

Adam

Yusuke Suzuki

unread,
Aug 20, 2013, 7:06:31 AM8/20/13
to Adam Barth, blink-dev, Kenneth Rohde Christiansen, Yutaka Hirano, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Kenji Baheux, Takeshi Yoshino
The design in your doc looks pretty reasonable.  I hope we can do better than ProtectedUntilNextTask, but we can iterate on that part in code review.  Here's a CL that sketches out a different approach to a related problem:
https://codereview.chromium.org/23254004/
That CL introduces the notion of a GarbageCollected object, which clients interact with via v8::Handles.  Instead of using something like ProtectedUntilNextTask, v8::Handles are naturally protected until the v8::HandleScope goes out of scope.  I wonder if we could use a similar approach here.

GarbageCollected object looks quite impressive.
Seeing this CL, I've come up with the idea of making ScriptPromiseContext managed by V8 GC. But this doesn't work in the following case,

PassRefPtr<Promise> A() {
    // This context is also refered by v8::HandleScope stack
    RefPtr<ScriptPromiseContext> context = ScrptPromiseContext::create(Promise::create(), Resolver::create());


    // context->releaseToGarbageCollector is called inside this getter.
    return context->promise();
}

PassRefPtr<Promise> B() {
    v8::HandleScope scope;
    ...
    return A();
}

PassRefPtr<Promise> C() {
    RefPtr<Promise> promise = B();

    ...
    Allocating v8 objects and V8 GC may work
    ...

    // At this point, JS<Promise>, JS<Resolver> and the Promise Associated Information may be collected.
    return promise;
}

Or is it OK not considering about this case? Is there any conventions about creating v8::HandleScope?

Erik Arvidsson

unread,
Aug 20, 2013, 11:03:05 AM8/20/13
to Adam Barth, Kenneth Rohde Christiansen, yusuke...@google.com, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Aaron Boodman, Kenji Baheux, Takeshi Yoshino, Alex Russell
On Tue, Aug 20, 2013 at 4:22 AM, Adam Barth <aba...@chromium.org> wrote:
> On Tue, Aug 20, 2013 at 1:18 AM, Kenneth Rohde Christiansen
> <kenneth.ch...@gmail.com> wrote:
>>
>> I think some SysApps specs intent to do that.
>
>
> Do you have some examples? It's not clear to me whether Promises should be
> treated as a JavaScript primitive like Function and Date or like a DOM
> object, like EventTarget.

Why does it matter?

I know we currently have different implementation strategies for these but...

We are moving towards the extensible web [1] and in such a world there
will be no way to tell the difference.

[1] http://extensiblewebmanifesto.org/

Also, eventually Promise will be part of ECMA 262 and our
implementation will most likely move into V8 at that point.
--
erik

Anne van Kesteren

unread,
Aug 20, 2013, 11:48:00 AM8/20/13
to Adam Barth, Kenneth Rohde Christiansen, Yusuke Suzuki, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Kenji Baheux, Takeshi Yoshino
On Tue, Aug 20, 2013 at 9:22 AM, Adam Barth <aba...@chromium.org> wrote:
> My sense is that Promises are relatively new and we should be conservative
> in how we use them for a while so that we can learn what works well and what
> doesn't work well.

Given the pushback on ProgressPromise in
http://lists.w3.org/Archives/Public/www-dom/2013JulSep/thread.html#msg113
in particular the end of
http://lists.w3.org/Archives/Public/www-dom/2013JulSep/0122.html I
think that's correct. If promises become a thing used at the level
suggested in that email, subclassing it might not make much sense
(although as arv points out that should be possible).


--
http://annevankesteren.nl/

Harald Alvestrand

unread,
Aug 20, 2013, 6:35:46 PM8/20/13
to Anne van Kesteren, Adam Barth, Kenneth Rohde Christiansen, Yusuke Suzuki, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Kenji Baheux, Takeshi Yoshino
If we create an implementation that doesn't allow subclassing, it's reasonable to expect that we won't see any useful implementations that use subclassing. So we won't learn if subclassing might have been useful.

OTOH, if we create an implementation that does allow subclassing, it's pretty certain that there'll be code out there that breaks if we later remove the facility.

Curst if you do, damd if you don't.


Kenji Baheux

unread,
Aug 20, 2013, 7:58:38 PM8/20/13
to Harald Alvestrand, Anne van Kesteren, Adam Barth, Kenneth Rohde Christiansen, Yusuke Suzuki, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Takeshi Yoshino
I would prefer the conservative approach as well:
  • Wouldn't we hear about the pain of not having an implementation that allow sub-classing?
  • We could use that feedback to judge if we need to allow subclassing.

Maybe, I am missing something...


2013/8/20 Harald Alvestrand <h...@google.com>

Adam Barth

unread,
Aug 20, 2013, 9:58:01 PM8/20/13
to Erik Arvidsson, Kenneth Rohde Christiansen, Yusuke Suzuki, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Aaron Boodman, Kenji Baheux, Takeshi Yoshino, Alex Russell, Anne van Kesteren, Harald Alvestrand
On Tue, Aug 20, 2013 at 8:03 AM, Erik Arvidsson <a...@chromium.org> wrote:
On Tue, Aug 20, 2013 at 4:22 AM, Adam Barth <aba...@chromium.org> wrote:
> On Tue, Aug 20, 2013 at 1:18 AM, Kenneth Rohde Christiansen
> <kenneth.ch...@gmail.com> wrote:
>>
>> I think some SysApps specs intent to do that.
>
> Do you have some examples?  It's not clear to me whether Promises should be
> treated as a JavaScript primitive like Function and Date or like a DOM
> object, like EventTarget.

Why does it matter?

I know we currently have different implementation strategies for these but...

That's the reason it matters.  Supporting subclassing add a large amount of complexity to the implementation.
 
We are moving towards the extensible web [1] and in such a world there
will be no way to tell the difference.

[1] http://extensiblewebmanifesto.org/

Authors might not be able to tell the difference based on the API we expose, but the mechanisms required to implement those APIs are very different.  Authors get to play in a world that's entirely visible to V8's garbage collector.  In the implementation, unfortunately, we don't have the luxury.

In parallel with this discussion, we're working on Oilpan, which will let us integrate better with V8's garbage collector and will dramatically reduce the complexity of supporting subclassing for Promises.  Oilpan isn't currently at a stage where we're blocking work on its completion, however.
 
Also, eventually Promise will be part of ECMA 262 and our
implementation will most likely move into V8 at that point.

We might want to change the implementation sooner rather than later.  The more complexity we pour into the implementation, the harder it will be to move inside the V8 API in the future.

On Tue, Aug 20, 2013 at 8:48 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
On Tue, Aug 20, 2013 at 9:22 AM, Adam Barth <aba...@chromium.org> wrote:
> My sense is that Promises are relatively new and we should be conservative
> in how we use them for a while so that we can learn what works well and what
> doesn't work well.

Given the pushback on ProgressPromise in
http://lists.w3.org/Archives/Public/www-dom/2013JulSep/thread.html#msg113
in particular the end of
http://lists.w3.org/Archives/Public/www-dom/2013JulSep/0122.html I
think that's correct. If promises become a thing used at the level
suggested in that email, subclassing it might not make much sense
(although as arv points out that should be possible).

If you mean possible by script, then I agree with you entirely.  :)

We should have a discussion at some point about how stable Promises are.  I'd like to ship the first version and get feedback from authors before adding more features.

On Tue, Aug 20, 2013 at 3:35 PM, Harald Alvestrand <h...@google.com> wrote:
If we create an implementation that doesn't allow subclassing, it's reasonable to expect that we won't see any useful implementations that use subclassing. So we won't learn if subclassing might have been useful.

OTOH, if we create an implementation that does allow subclassing, it's pretty certain that there'll be code out there that breaks if we later remove the facility.

Curst if you do, damd if you don't.

I'm not sure I follow your logic.  If we hold off on supporting subclassing, we'll learn how well Promises work without subclassing.  If they work well, great.  If we find that many use cases require subclassing, then we can implement subclassing.

On Tue, Aug 20, 2013 at 4:58 PM, Kenji Baheux <kenji...@chromium.org> wrote:
I would prefer the conservative approach as well:
  • Wouldn't we hear about the pain of not having an implementation that allow sub-classing?
  • We could use that feedback to judge if we need to allow subclassing.
Maybe, I am missing something...
 
That sounds like a good approach to me.

Adam

Yutaka Hirano

unread,
Aug 20, 2013, 10:14:59 PM8/20/13
to Kenji Baheux, Harald Alvestrand, Anne van Kesteren, Adam Barth, Kenneth Rohde Christiansen, Yusuke Suzuki, blink-dev, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Takeshi Yoshino
Yusuke's design makes it enable to handle the Promise type on IDL files, which is impossible with the current implementation.
It is an advantage even if we don't want to subclass Promise.

Harald Alvestrand

unread,
Aug 21, 2013, 5:40:28 AM8/21/13
to Yutaka Hirano, Kenji Baheux, Anne van Kesteren, Adam Barth, Kenneth Rohde Christiansen, Yusuke Suzuki, blink-dev, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Takeshi Yoshino
There are many proposals to use Promises on APIs that are presently in IDL files, so being able to use Promises in IDL files seems important to me.

I agree that not allowing subclassing seems like the natural conservative approach.

Justin Novosad

unread,
Aug 21, 2013, 9:52:30 AM8/21/13
to Harald Alvestrand, Yutaka Hirano, Kenji Baheux, Anne van Kesteren, Adam Barth, Kenneth Rohde Christiansen, Yusuke Suzuki, blink-dev, Benjamin Kalman, Alec Flett, Erik Arvidsson, Aaron Boodman, Takeshi Yoshino
On Wed, Aug 21, 2013 at 5:40 AM, Harald Alvestrand <h...@google.com> wrote:
There are many proposals to use Promises on APIs that are presently in IDL files, so being able to use Promises in IDL files seems important to me.

Just to be clear, although Promise can't be used in IDL files today, it is still possible to specify API bindings that use promises in IDL.  We already have APIs that do so by using "typedef any PromiseValue;".  Sure, that's not ideal, but we can live with that, at least for now.

Anne van Kesteren

unread,
Aug 21, 2013, 12:49:57 PM8/21/13
to Adam Barth, Erik Arvidsson, Kenneth Rohde Christiansen, Yusuke Suzuki, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Aaron Boodman, Kenji Baheux, Takeshi Yoshino, Alex Russell, Harald Alvestrand
On Wed, Aug 21, 2013 at 2:58 AM, Adam Barth <aba...@chromium.org> wrote:
> On Tue, Aug 20, 2013 at 8:48 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
>> Given the pushback on ProgressPromise in
>> http://lists.w3.org/Archives/Public/www-dom/2013JulSep/thread.html#msg113
>> in particular the end of
>> http://lists.w3.org/Archives/Public/www-dom/2013JulSep/0122.html I
>> think that's correct. If promises become a thing used at the level
>> suggested in that email, subclassing it might not make much sense
>> (although as arv points out that should be possible).
>
> If you mean possible by script, then I agree with you entirely. :)

Yes, via script.


> We should have a discussion at some point about how stable Promises are.
> I'd like to ship the first version and get feedback from authors before
> adding more features.

I'm trying to get TC39 folks to reach a conclusion. There's another
meeting near the end of September and by then there better be
agreement on a subset of the design which we can start shipping
(modulo event loop changes). To be clear, discussion is ongoing today,
I just hope that at the meeting we can declare "consensus".


--
http://annevankesteren.nl/

Adam Barth

unread,
Aug 21, 2013, 12:53:04 PM8/21/13
to Anne van Kesteren, Erik Arvidsson, Kenneth Rohde Christiansen, Yusuke Suzuki, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Aaron Boodman, Kenji Baheux, Takeshi Yoshino, Alex Russell, Harald Alvestrand
Great.  Thanks!

Adam

Yusuke Suzuki

unread,
Aug 22, 2013, 11:52:05 PM8/22/13
to Adam Barth, Anne van Kesteren, Erik Arvidsson, Kenneth Rohde Christiansen, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Aaron Boodman, Kenji Baheux, Takeshi Yoshino, Alex Russell, Harald Alvestrand
I understood subclassing is still controversial. This should be discussed after the consensus is declared.
However I think making Promise IDL-friendly is important and we'd like to implement it.
So I'll change the purpose of the design document to making Promise IDL-friendly.

Even if this change is landed, we can prohibit subclassing Promise.
And this change keeps compatibility with old interfaces like ScriptPromiseResolver.

And I have a question, Adam.

The design in your doc looks pretty reasonable.  I hope we can do better than ProtectedUntilNextTask, but we can iterate on that part in code review.  Here's a CL that sketches out a different approach to a related problem: 

https://codereview.chromium.org/23254004/ 

That CL introduces the notion of a GarbageCollected object, which clients interact with via v8::Handles.  Instead of using something like ProtectedUntilNextTask, v8::Handles are naturally protected until the v8::HandleScope goes out of scope.  I wonder if we could use a similar approach here.

If we implement it by using a GarbageCollected ScriptPromiseContext object, it raises the problem. https://groups.google.com/a/chromium.org/d/msg/blink-dev/9q5kP0eMQc8/sGpXa_TbwSkJ
Is it not necessary to consider about this case? Is there any conventions about creating v8::HandleScope in Blink?

Adam Barth

unread,
Aug 23, 2013, 12:42:17 AM8/23/13
to Yusuke Suzuki, Anne van Kesteren, Erik Arvidsson, Kenneth Rohde Christiansen, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Aaron Boodman, Kenji Baheux, Takeshi Yoshino, Alex Russell, Harald Alvestrand
On Thu, Aug 22, 2013 at 8:52 PM, Yusuke Suzuki <yusuke...@chromium.org> wrote:
I understood subclassing is still controversial. This should be discussed after the consensus is declared.
However I think making Promise IDL-friendly is important and we'd like to implement it.
So I'll change the purpose of the design document to making Promise IDL-friendly.

Even if this change is landed, we can prohibit subclassing Promise.
And this change keeps compatibility with old interfaces like ScriptPromiseResolver.

And I have a question, Adam.

The design in your doc looks pretty reasonable.  I hope we can do better than ProtectedUntilNextTask, but we can iterate on that part in code review.  Here's a CL that sketches out a different approach to a related problem: 

https://codereview.chromium.org/23254004/ 

That CL introduces the notion of a GarbageCollected object, which clients interact with via v8::Handles.  Instead of using something like ProtectedUntilNextTask, v8::Handles are naturally protected until the v8::HandleScope goes out of scope.  I wonder if we could use a similar approach here.

If we implement it by using a GarbageCollected ScriptPromiseContext object, it raises the problem. https://groups.google.com/a/chromium.org/d/msg/blink-dev/9q5kP0eMQc8/sGpXa_TbwSkJ
Is it not necessary to consider about this case? Is there any conventions about creating v8::HandleScope in Blink?

Instead of returning a PassRefPtr<Promise>, you can return a v8::Handle<v8::Value> for the Promise.

If we're going to iterate on our Promise implementation, I wonder if we should take this opportunity to move the implementation inside of V8.  That's likely where we're going to want the implementation eventually anyway.  If we did that, we'd return a v8::Handle<v8::Promise> instead, which is a more accurate type.

Adam

Yusuke Suzuki

unread,
Aug 23, 2013, 6:34:08 AM8/23/13
to Adam Barth, Anne van Kesteren, Erik Arvidsson, Kenneth Rohde Christiansen, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Aaron Boodman, Kenji Baheux, Takeshi Yoshino, Alex Russell, Harald Alvestrand
Instead of returning a PassRefPtr<Promise>, you can return a v8::Handle<v8::Value> for the Promise.

Thanks! I see.
Writing the Promise type in IDL seems to be solved by IDL code generator, the code generator recognizes the Promise type and maps it to ScriptPromise like DOMString.
That sounds very nice.

Anne van Kesteren

unread,
Aug 23, 2013, 7:13:30 AM8/23/13
to Adam Barth, Domenic Denicola, Yusuke Suzuki, Erik Arvidsson, Kenneth Rohde Christiansen, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Aaron Boodman, Kenji Baheux, Takeshi Yoshino, Alex Russell, Harald Alvestrand
On Fri, Aug 23, 2013 at 5:42 AM, Adam Barth <aba...@chromium.org> wrote:
> If we're going to iterate on our Promise implementation, I wonder if we
> should take this opportunity to move the implementation inside of V8.
> That's likely where we're going to want the implementation eventually
> anyway. If we did that, we'd return a v8::Handle<v8::Promise> instead,
> which is a more accurate type.

The next iteration of promises for the DOM specification will probably
define it mostly in terms of ES6 language as the plan is for it to end
up in JavaScript long term indeed.

https://github.com/domenic/promises-unwrapping is Domenic's awesome
work on this. I haven't had a time to do a detailed review yet, but it
is the outcome of a long discussion with TC39 members and I strongly
suspect we'll be able to get consensus on that model. This model also
makes it possible to support promises-for-promises at a later stage,
so we can start out slightly simpler.


--
http://annevankesteren.nl/

Yusuke Suzuki

unread,
Aug 26, 2013, 11:27:52 PM8/26/13
to Anne van Kesteren, Adam Barth, Domenic Denicola, Erik Arvidsson, Kenneth Rohde Christiansen, blink-dev, Yutaka Hirano, Benjamin Kalman, Alec Flett, Aaron Boodman, Kenji Baheux, Takeshi Yoshino, Alex Russell, Harald Alvestrand
Since Promise and PromiseResolver will be implemented in V8 as JS objects in the future, it seems we should add a special conversion rule to the IDL code generator to treat the Promise and PromiseResolver types in IDL, such as DOMString -> const String&.

So we intend to implement the Promise and PromiseResolver types in IDL by introducing the following special mappings to IDL code generator.
    Promise -> ScriptPromise
    PromiseResolver -> ScriptPromiseResolver

cow...@bbs.darktech.org

unread,
Sep 23, 2013, 4:46:34 PM9/23/13
to blin...@chromium.org, Kenji Baheux, tyos...@google.com
Out of curiosity, what is the relationship between DOM Promises as mentioned in the spec and q.js as found at https://github.com/kriskowal/q ?

Instead of mandating a specific definition of Promises, would it be possible to standardize design primitives that are common to q.js, when.js and all other Promise implementations such that they will all see performance benefits without DOM Promises replacing these libraries (which I believe are superior)?

Thank you,
Gili

On Thursday, May 23, 2013 12:28:03 PM UTC-4, Takeshi Yoshino wrote:

Primary eng/PM emails

Eng tyos...@chromium.org, PM kenji...@chromium.org


Spec

WHATWG DOM Standard http://dom.spec.whatwg.org/#futures


Summary

Futures provide a convenient way to get access to the result of an operation that may have already occurred or may happen in the future.


Futures can be returned by platform APIs, but can also be used in conjunction with an existing API to make it easier to work with. See the examples on the spec and Alex’s old doc https://github.com/slightlyoff/Futures.


Motivation

Allow asynchronous processing code to represent data dependency in more readable form. Planned to be applied to Streams, XMLHttpRequest, File/Blob, etc.


We are seeking for a new better I/O API. Some people on the spec discussion list suggested that we should tryout DOM Futures to implement streaming access API for XMLHttpRequest's result and request body. See also the Blink review thread for Streams API [1]


Compatibility Risk

None. To be implemented behind a runtime flag. There’s still active discussion on the Futures spec at public-...@w3.org.


Ongoing technical constraints

None


Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes


OWP launch tracking bug?

crbug.com/243345


Row on feature dashboard?

Yes


Requesting approval to ship?

No


Joshua Bell

unread,
Sep 23, 2013, 8:01:48 PM9/23/13
to cow...@bbs.darktech.org, blink-dev, Kenji Baheux, Takeshi Yoshino
You should probably start by reading http://infrequently.org/2013/06/sfuturepromiseg/ which enumerates the design inputs to DOM Promises (including those you mentioned), then read the archives of public-script-coord http://lists.w3.org/Archives/Public/public-script-coord/ starting in about June 2013 to gain an understanding of how the design evolved since then. (And you may want to go back as far as April 2013 to see some of the grizzly details.)

If you have additional feedback which you believe is not covered in the (rather lengthy) discussions so far, public-script-coord is the place to raise it so all implementers can participate.

Yutaka Hirano

unread,
Nov 1, 2013, 7:56:19 AM11/1/13
to blink-dev
Reply all
Reply to author
Forward
0 new messages