- From: John J Barton <johnjbarton@johnjbarton.com>
- Date: Mon, 13 Feb 2012 12:08:10 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: Joshua Bell <jsbell@chromium.org>, Jonas Sicking <jonas@sicking.cc>, public-webapps@w3.org, David Levin <levin@chromium.org>
On Mon, Feb 13, 2012 at 11:44 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Thu, 17 Nov 2011, Joshua Bell wrote:
>>
>> Wouldn't it be lovely if the Worker script could simply make a
>> synchronous call to fetch data from the Window?
>
> It wouldn't be so much a synchronous call, so much as a blocking get.
>..
> Anyone object to me adding something like this? Are there any better
> solutions? Should we just tell authors to get used to the async style?
I guess the "Q" folks would say that remote promises provides another
solution. If promises are adopted by the platform, then the async
style gets much easier to work with.
https://github.com/kriskowal/q
(spec is somewhere on the es wiki)
In the Q model you would fetch data like:
parentWindow.fetchData('myQueryString').then( // block until reply.
function(data) {...},
function(err) {...}
);
Q has functions to join promises; q_comm add remote promises.
I believe this can be done today with q_comm in workers.
Your signal/yieldUntil looks like what es-discuss calls "generators".
I found them much harder to understand than promises, but then I come
from JS not python.
jjb
Received on Monday, 13 February 2012 20:08:37 UTC