- 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