W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: TAG feedback on Web Audio

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Fri, 02 Aug 2013 00:29:32 -0400
Message-ID: <51FB35AC.7000805@arcanedomain.com>
To: Alex Russell <slightlyoff@google.com>
CC: Chris Wilson <cwilso@google.com>, Anne van Kesteren <annevk@annevk.nl>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, "robert@ocallahan.org" <robert@ocallahan.org>, "public-audio@w3.org" <public-audio@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>
As I said before, I think it would be useful to capture the key insights 
from this discussion in some sort of TAG (or other) Recommentation or 
Finding that will make clearer to the community >why< data races are an 
anti-pattern at least for Javascript on the Web, and of course in many 
other situations too.


On 8/1/2013 8:42 PM, Alex Russell wrote:
> Let me be clearer, then: the issue is that it introduces effects to JS that
> can't be described /in terms of JS/. It violates the run-to-completion
> model of the language without appealing to the turn-based concurrency model
> we use everywhere else in the platform.
> On Wed, Jul 31, 2013 at 10:43 AM, Chris Wilson <cwilso@google.com
> <mailto:cwilso@google.com>> wrote:
>     In addition, I'd ask that you be more explicit than calling this
>     problem "data races", because there's clearly some explicit effect
>     you're trying to prevent.  Any asynchronously-programmable or
>     event-driven system can enable developers to introduce race conditions.
>     On Mon, Jul 29, 2013 at 10:09 PM, Noah Mendelsohn <nrm@arcanedomain.com
>     <mailto:nrm@arcanedomain.com>> wrote:
>         On 7/29/2013 7:05 PM, Anne van Kesteren wrote:
>             On Sat, Jul 27, 2013 at 9:22 AM, Noah
>             Mendelsohn<nrm@arcanedomain.__com
>             <mailto:nrm@arcanedomain.com>>  wrote:
>                  >Again, I have no informed opinions on the specific
>                 merits, just suggesting a
>                  >useful role the TAG might play to clarify for the many
>                 members of the
>                  >community who are less expert on this than you are. Thank
>                 you.
>             I'm not sure we call out data races anywhere, it's something we
>             just don't do.
>         Well, my recollection may be faulty, but I think that one of the
>         reasons the TAG took the trouble to formalize things like the
>         architecture document was the belief that it's easier to ask
>         skeptics to stick to rules that have been written down, and
>         especially those that have garnered formal consensus through
>         something like the Recommendation track.
>         Whether it's worth taking a guideline on data races all the way to
>         Rec I'm not sure, but it seems that it would be worth setting it
>         down formally, perhaps in a TAG Finding/blog post/Recommendation or
>         whatever will get the right level of discussion, consensus
>         building, and eventually attention.
>         Certainly, of the many things that have come up recently relating
>         to APIs, this one seems deeply architectural and very much within
>         the TAG's remit.
>         Noah
Received on Friday, 2 August 2013 04:29:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC