W3C Process, Consensus and Decision Making (Re: New proposal for fixing race conditions)

Everyone,

I want to thank you all for your participation in this conversation. I
understand there are strong feelings about which is the right approach,
and some important competing principles at play.

As co-chair, I will note that we have had at least three proposals,
including the status quo, the initial proposal by ROC a few weeks ago and
the recent proposal by Jer. Our ideal scenario would have been to have one
proposal with unanimous buy-in or consensus. That is not the case. We will
not have a "best solution" and need to set our sights on a "best
compromise" which ideally everyone can live with.

My understanding of the recent discussion is that Jer's proposal [1] is
gathering significant consensus in the group. A number of participants
desiring to fix the race condition seem to find it an acceptable solution
[2][3], others less certain about the need to fix the potential race
condition (including Jer) seem to find it an acceptable compromise too.
This proposal is raising at least one objection, by Chris Rogers (see
below for quoted message).

[1] http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0162.html

[2] http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0167.html

[3] http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0180.html

[4] http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0178.html



Now seems like a good time to point everyone to sections 3.3 and 3.4 of
the W3C process, which governs our working group and which we all signed
up to follow when we formally joined the group.

http://www.w3.org/2005/10/Process-20051014/policies#Consensus

http://www.w3.org/2005/10/Process-20051014/policies#Votes



Chris (Rogers), you have written that you can not support the proposed
solution. Given where we are in the decision process, please state whether
you can live with it (even though you do not support it) or whether you
can not live with it (i.e. You are raising an objection). Clarifications
about whether you could live with elements of the proposal would also be
valuable. I encourage anyone opposed to the solution to do the same in the
next few days if for some reason you oppose the solution but haven't
spoken up yet.

As per our process, the co-chairs will assess the situation (early next
week, if possible) and decide whether we can follow the route of recording
consensus and any objection, or whether we need to move to a vote.

In the meantime, I do of course encourage you to continue the discussion.
Any effort in refining proposals with some consensus around them will be
useful.


Kind regards,
Olivier




On 19/07/2013 19:54, "Chris Rogers" <crogers@google.com> wrote:

>Jer, thanks for sharing the proposal.
>
>
>I can't support a solution like this because it:
>
>
>1. Forces the need for copies both for setting and reading data.  PCM
>data is large and it's inefficient to be required to copy.
>2. It needlessly complicates the API, where we now have a simple solution.
>3. The "problem" it is supposed to solve is effectively a non-issue.
>
>
>Chris
>
>
>
>
>
>On Thu, Jul 18, 2013 at 1:02 PM, Jer Noble
><jer.noble@apple.com> wrote:
>
>Overview
>In order to solve the "data race" issue in WebAudio (bug 22725
><https://www.w3.org/Bugs/Public/show_bug.cgi?id=22725>), this proposal
>restricts access to the internal PCM data of an AudioBuffer. This
> does not require AudioBuffers to be immutable, but that modifying their
>contents occurs through an API which enforces no-data-race semantics.
>Since this will involve breaking API changes, this proposal incorporates
>suggestions from Issue 48
><https://www.w3.org/Bugs/Public/show_bug.cgi?id=17341> to simplify the
>AudioBuffer interface, and will
> also adopt a constructor, as opposed to a factory method.
>The new constructor provides an upgrade path for existing pages while not
>breaking those pages. The factory method can continue to create the
>"legacy" AudioBuffer in prefixed implementations.
>Note: I still prefer the "Immutable ArrayBuffer" proposal.
>New interfaces
>AudioBufferChannel
>This interface represents a single channel of an AudioBuffer.
>interface AudioBufferChannel {
>    readonly attribute unsigned long length;
>
>    void set(Float32Array array, optional unsigned long offset);
>    Float32Array slice(long begin, optional long end);
>};
>
>Attributeslength
>
>* Length of the PCM audio data in sample-frames.
>
>Methodsset
>
>* Copies the Float32Array representing the PCM audio data.
>
>* An INDEX_SIZE_ERR exception must be thrown if the length ofarray plus
>offset exceeds
> the length of the available audio data.
>
>* An NO_MODIFICATION_ALLOWED_ERR exception must be thrown if the
>AudioBufferChannel is currently is use by a live AudioNode.
>
>
>slice
>
>* Returns a copy of the underlying PCM audio data. If eitherbegin or end
>is
> negative, it refers to an index from the end of the audio data.
>
>* If end is
> unspecified, the copy will include all the data frombegin to
> the end of the audio data.
>
>* The range specified by begin and end is
> clamped to the valid range for the audio data. If the computed length of
>the copied data would be negative, it is clamped to zero.
>
>
>AudioBuffer[Constructor(unsigned long numberOfChannels, unsigned long
>length, float sampleRate)]
>interface AudioBuffer {
>
>    readonly attribute float sampleRate;
>
>    // in seconds
>    readonly attribute double duration;
>
>    readonly attribute AudioBufferChannel[] channels;
>};
>
>AttributessampleRate
>
>* The sample-rate for the PCM audio data in samples per second.
>
>duration
>
>* Duration of the PCM audio data in seconds.
>
>channels
>
>* An array of AudioBufferChannel objects representing the PCM audio data
>for each audio channel.
>
>* This array is of fixed length and is read-only.
>
>
>Alternatives
>Immutable ArrayBuffer
>To make ArrayBuffer immutable, the set() method
> would be removed from ArrayBufferChannel.
>interface ArrayBufferChannel {
>    readonly attribute unsigned long length;
>    Float32Array slice(long begin, optional long end);
>};
>
>This would require a different constructor method on ArrayBuffer.
>[Constructor(Float32Array[] arrays, float sampleRate)]
>
>This would also require the outputBuffer attribute
> on AudioProcessingEvent to drop the 'readonly' declaration.
>partial interface AudioProcessingEvent {
>    attribute AudioBuffer outputBuffer;
>};
>
>Backwards Compatibility Not
> normative
>WebKitAudioBufferinterface WebKitAudioBuffer : AudioBuffer {
>    readonly attribute length;
>
>    readonly attribute long numberOfChannels;
>
>    Float32Array getChannelData(unsigned long channel);
>};
>
>WebKitAudioContextpartial interface WebKitAudioContext {
>    WebKitAudioBuffer createBuffer(unsigned long numberOfChannels,
>unsigned long length, float sampleRate);
>};
>
>WebKit will continue to support WebKitAudioBuffer objects in the prefixed
>version of the API for every attribute or parameter which currently
>specifies AudioBuffer. WebKit will drop WebKitAudioBuffer support in the
>unprefixed API.
>
>
>
>
>
>
>




-----------------------------
http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Saturday, 20 July 2013 12:14:00 UTC