W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: Blocking message passing for Workers

From: Brendan Eich <brendan@secure.meer.net>
Date: Tue, 12 Aug 2014 12:25:52 -0700
Message-ID: <53EA6A40.6040604@secure.meer.net>
To: David Bruant <bruant.d@gmail.com>
CC: Brian Kardell <bkardell@gmail.com>, Glenn Maynard <glenn@zewt.org>, adelespinasse@gmail.com, public-webapps WG <public-webapps@w3.org>, Alon Zakai <azakai@mozilla.com>
David Bruant wrote:
> I proposed exposing both here 
> http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0164.html
> Jonas Sicking wasn't sold 
> http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0165.html

You didn't reply, but we now have a good argument thanks to your point 
here, about reusing async-only JS libraries.

> And I haven't found later replies on this topic.

Alon replied to Jonas, saying somewhat more gently what I said about 
generators/async-functions/whole-program-CPS-conversion being infeasible 
for Emscripten:

http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0175.html

Jonas's desire for parsimony is a good design bias, but we now have a 
reason to consider async as well as sync APIs for workers.

However, I'd still want some case analysis. Do we see Emscripten using 
IndexedDB to emulate a synchronous filesystem? If we have a sync f/s API 
that's closer to Unix/C, perhaps there's no Emscripten-based need. 
Cc'ing Alon, assuming Jonas will catch up on the list.

/be
Received on Tuesday, 12 August 2014 19:26:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC