Re: TAG feedback on Web Audio

On Sun, Aug 4, 2013 at 6:46 PM, Chris Wilson <cwilso@google.com> wrote:

> (Sorry, on vacation, and beach > Web Audio discussions. :)
>
> Alex, as we discussed a few weeks ago - glitch-free,
> reasonably-low-latency audio is something that I just don't believe JS - *as
> it is today - *can do.
>

In the TAG feedback document you might have detected two lines of attack on
this argument:


   1. It's insufficient to say "JavaScript can't do this". The entire goal
   of some of the suggestions in the document related to the execution model
   are all about creating space in the model to change the constraints under
   which JS (or something else) runs such that JS* *(or ASMJS or NaCL in a
   worker, etc.) *could* do what's needed without breaking the invariants
   of either the platform or the conceptual semantic model that Web Audio
   presents. So that's simply an argument against an assertion *that hasn't
   been presented*. It fails on that ground alone, however...
   2. Nothing in my argument against breaking the platform invariants
   requires that you actually RUN the built-in node types in JS. To some great
   degree, I'm advocating for JS-as-spec-language when I discuss de-sugaring.
   Not an implementation strategy (except perhaps in naive cases for
   newly-bootstrapping impls).

The net is that discussing main-thread-JS-as-we-know-it-today and not the
framework for execution/specification is arguing against an
implementation-level straw-man.

Regards

On Thu, Aug 1, 2013 at 5:42 PM, Alex Russell <slightlyoff@google.com> 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> 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>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 <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
>>>>
>>>>
>>>
>>
>