Re: Sites using webkitAudioContext only

On Thu, Jun 20, 2013 at 11:14 AM, Chris Wilson <cwilso@google.com> wrote:

>  As I think I previously mentioned, I actually don't think constructors
>>> is a good idea here (as most of the nodes have a direct relationship with
>>> the context).
>>>
>>
>> You can just pass in the context to the constructor, so this is not
>> really a huge issue.
>>
>
> I fail to see how that's better.  You then have to define for each
> constructor what happens if it's null, or invalid, ... all for what to me
> is simply a stylistic change.  Am I missing some innate value of this
> pattern?
>

Yes, it is simply a stylistic change, sorry if I was not clear about this
before.


>
>
>> It's true that we can standardize Web Audio with these C-style creator
>> APIs and things will work in practice, but we will end up with a non-webby
>> API.
>>
>
> I don't think this makes Web Audio "non-webby".  I use
> document.createElement() all the time.
>

document.createElement() is very old.  See things like creating events,
blobs, XHR, WebSockets, ranges, speech API, Audio(), Image(), etc.  :-)


>
>
>> That's not a deal breaker, but we have the potential to fix this problem
>> now if all of the three engines implementing Web Audio cooperate.
>> Otherwise, I don't have a lot of hope of this being possible in a V2 of the
>> spec -- that is, we might spec and implement a better API, but the damage
>> of the current API will be done for everybody who has already learned and
>> used the API, and it will ripple through other web developers for some time.
>>
>
> I agree that this isn't something that could be pushed to v2.  I don't see
> the value of it, however.
>

There is some value in designing APIs which fit well with other APIs on the
Web platform.  It's not the end of the world if Web Audio won't be such an
API, but all else equal, we should make an effort to make it such.


>
>
>> Other than decoding - and there, honestly, I think there's room for a
>>> fuller API in the future - and possible getUserMedia, nothing leaps to mind
>>> that needs Promises.
>>>
>>
>> If we fixed all of the other issues and only left this one unresolved, I
>> would be a happy man!
>>
>
>  Question remains - is there a place we should be using promises?
>  Decoding, I guess?
>

Yes, specifically decodeAudioData can return a promise.


>  Is there any way we can quantify and address any such issues ASAP,
>>> because I think we need to be talking about large changes before small ones.
>>>
>>
>> Hmm, not sure what you mean by quantify -- we can't do that without data,
>> which we don't have.
>>
>
> I meant even just list precisely what changes we were talking about.
>

I'm open to discuss all of these items in more detail, but I feel like
without knowing more about what Blink is going to do, this will be a
discussion which will only be interesting at an intellectual level and
won't have any practical impact.  Which is why I've repeatedly asked for
clarification on that in this thread, so far without a response.


>  Blink or Webkit could ship unprefixed - but frankly, the other issues
>>> above are leaving me more concerned about making that change now.
>>>
>>
>> Which change are you referring to?
>>
>
> Making the change to support unprefixed.  If we're talking about a large
> set of breaking changes, deploying that across webkit, blink, and gecko
> consistently for developers would be challenging.
>

None of the changes that we're discussing here would affect the processing
code underlying the implementations.  Removal of things like alternate
names and the synchronous createBuffer should be very easy.  Larger API
changes are more time consuming, for sure, and as I've said before I'd be
open to commit to doing that if Blink and WebKit (or at least Blink) does
the same, even if that means that Gecko would need to delay the release by
one cycle.  I'd be very surprised if the changes would take more time than
that for Blink and WebKit, given my understanding from their implementation.


>  Most of the carrots we can offer web developers are evangelism efforts.
>> I'm not aware of any such efforts having started so far, so honestly I'm
>> not holding my breath for it to suddenly start happening now.  The stick,
>> however, is the prefixed implementation.  Chrome can either use that to
>> unprefix AudioContext and remove the webkitAudioContext as soon as
>> possible, or to make other engines conform to what it's currently
>> shipping.  So far it has been using it in the latter direction.  I remember
>> from the f2f conversations (please correct me if I'm wrong) that Chris
>> Rogers was against removing webkitAudioContext for a long period of time
>> (possibly 1-2 years if I remember the conversation correctly), which really
>> worries me.
>>
>
> This all being said, I think we've talked about all of the possible
>> directions we can possibly take quite extensively thus far.  Let's give
>> Chris Rogers a chance to catch up with the thread and comment on it, and
>> then we can discuss which path forward we should be taking.
>>
>
> To be clear, I've been having conversations with Chris about this on the
> side; he's been paying attention, and I'm sure he will chime in if I say
> anything he wildly disagrees with.  He's just busy.
>
> I think I am safe in saying both Chris and I are on board with:
> -removing the old names from the spec
> -NOT implementing them in unprefixed AudioContext
> -putting in console warnings in using them in webkitAudioContext, and
> working to minimize their use in order to remove them completely.
>
> I think we are both also agreed that we don't currently see value in
> changing the creator/constructor pattern, nor where promises should be
> applied, and if there are any other bikeshedding changes (is Analyser ->
> Analyzer still an issue?) - I don't recall if we've specifically discussed
> the sync decode issue, so maybe that's a place we should use Promises, but
> it's going to be hard to remove what's there.
>

Great!  I'm hoping to hear more about the timeline for unprefixing and
adopting these changes in Blink from Chris (Rogers) in today's teleconf.
:-)

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>