- From: Ehsan Akhgari <ehsan.akhgari@gmail.com>
- Date: Fri, 9 Aug 2013 15:10:25 -0400
- To: Joseph Berkovitz <joe@noteflight.com>
- Cc: Chris Lowis <chris.lowis@bbc.co.uk>, "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <CANTur_7DrRkahjHjNDAaqPzDV6d2dnkxsaDXr+V61tEDGZ7v+g@mail.gmail.com>
On Fri, Aug 9, 2013 at 9:59 AM, Joseph Berkovitz <joe@noteflight.com> wrote: > On Aug 9, 2013, at 5:18 AM, Chris Lowis <chris.lowis@bbc.co.uk> wrote: > > This is a good point. If we go to a vote it needs to be clear what people > are voting on and what the implications will be. > > > Clarity on every option would be ideal. However, we are at an impasse that > is holding back everyone's progress, both browser implementors and > developers. > Yes, unfortunately. :-( > I appreciate the chair's efforts in trying to reach consensus and I > understand that August is a tough time to crack the schedule whip. But at > this point I would like to request that the chair set a firm deadline for > finalization of the proposals, followed by a firm voting date. If one of > the options is not clear after the finalization date, that can hardly be > the fault of the voting process. > I would really prefer having fixed dates as well. > Also, if the shared-memory approach isn't clarified further, perhaps the > de facto content of the option is, "the behavior in <some set of potential > race situations> is unspecified". I don't see it as a requirement for > *voting* that the shared-memory approach absolutely nail down how race > conditions work (or even commit to doing so in the future). However > attractive or unattractive, one can still vote for or against a position > that the outcome under potential race conditions is indeterminate. > Well, but what would the behavior being unspecified actually means? One could interpret that as either what WebKit/Blink and Gecko implement today, and they're clearly not the same and not completely inter-operable. I think what the proponents of the "let things be" solution really want is shared memory access between the main thread and the audio thread, and leaving things unspecified is a little bit shying away from saying that explicitly. There are many reasons why shared memory access is not OK as discussed within the past few weeks, and I would like us to have a detailed proposal from this side too which addresses what the exact behavior needs to be and why the trade-offs towards shared memory access are being made, especially since this will have drastic effect on environments which do not provide shared memory at all. Cheers, -- Ehsan <http://ehsanakhgari.org/>
Received on Friday, 9 August 2013 19:11:34 UTC