- From: Joshua Bell <jsbell@chromium.org>
- Date: Thu, 17 Nov 2011 10:37:14 -0800
- To: public-webapps@w3.org
- Message-ID: <CAD649j4rss+dmBGOXz4YK5bihieHJ-uarEMZgH=nfRi84+O+tA@mail.gmail.com>
Jonas and I were having an offline discussing regarding the synchronous Indexed Database API and noting how clean and straightforward it will allow Worker scripts to be. One general Worker issue we noted - independent of IDB - was that there are cases where Worker scripts may need to fetch data from the Window. This can be done today using bidirectional postMessage, but of course this requires the Worker to then be coded in now common asynchronous JavaScript fashion, with either a tangled mess of callbacks or some sort of Promises/Futures library, which removes some of the benefits of introducing sync APIs to Workers in the first place. Wouldn't it be lovely if the Worker script could simply make a synchronous call to fetch data from the Window? GTNW.prototype.end = function () { var result = self.sendMessage({action: "prompt_user", prompt: "How about a nice game of chess?"}); if (result) { chess_game.begin(); } } The requirement would be that the Window side is asynchronous (of course). Continuing the silly example above, the Window script responds to the message by fetching some new HTML UI via async XHR, adding it to the DOM, and only after user input and validation events is a response sent back to the Worker, which proceeds merrily on its way. I don't have a specific API suggestion in mind. On the Worker side it should take the form of a single blocking call taking the data to be passed and possibly a timeout, and allowing a return value (on timeout return undefined or throw?). On the Window side it could be a new event on Worker which delivers a "Promise" type object which the Window script can later fulfill (or break). Behavior on multiple event listeners would need to be defined (all get the same "Promise", first "fulfill" wins, others throw?).
Received on Thursday, 17 November 2011 18:37:43 UTC