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?
Row on feature dashboard?
Yes
Requesting approval to ship?
NoGood 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 ....
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].
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.
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?
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.
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'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.
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
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.
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.
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.
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.
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
I think some SysApps specs intent to do that.
WebCrypto doesn't need subclassing anymore. Are we sure we want to support subclassing Promise?
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.
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.
On Tue, Aug 20, 2013 at 4:22 AM, Adam Barth <aba...@chromium.org> wrote:Why does it matter?
> 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.
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.
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 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 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...
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.
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.
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_TbwSkJIs 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.
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?
Row on feature dashboard?
Yes
Requesting approval to ship?
No