Re: The issue of ScriptProcessorNode not being an EventTarget

On Mon, Mar 4, 2013 at 4:10 PM, Joe Berkovitz <joe@noteflight.com> wrote:

> FYI I had hoped to discuss this on last Thursdays call.
>
> I think it's an important point to resolve as soon as we can. But I sure
> don't want to slow down an implementation by waiting for the resolution.
>
> Chris, can you remind us why this case should not follow the general
> pattern of event target/handler pairs? I'm hard pressed to think of other
> cases where one would only have an "on" callback with no associated
> dispatchable event, and it seems plausible (though not obvious) that one
> could have multiple listeners in this case.
>

I'm sorry, my mistake.  I just realized we *are* talking about
ScriptProcessorNode, when I thought we were talking about
OfflineAudioContext.  I think it's very bad to have multiple listeners for
ScriptProcessorNode because it's important to process the output only one
time per "callback".  Otherwise, a clean continuous output stream would not
be generated.  Thus it really needs to be a callback and not an
EventListener.  Let's not drive the decision based on the current name of
the attribute.

As for the naming we can either:

1.  live with the fact that "onaudioprocess" *seems" to imply an
EventListener, although it really is a callback.  I'm not sure if there's
any explicit rule that a callback can not in any circumstances have this
naming convention.  If there is such a rule, then it seems a bit silly.

2. Change the name of the callback to something different and break all
current pages using this node.  My opinion is that this would be a very
serious breaking change.

I prefer option (1)

Chris


>
> .       .    .  . ...Joe
>
> *Joe Berkovitz*
> President
> Noteflight LLC
> +1 978 314 6271
> www.noteflight.com
> "Your music, everywhere."
>
> On Mar 4, 2013, at 6:38 PM, Chris Rogers <crogers@google.com> wrote:
>
>
>
> On Mon, Mar 4, 2013 at 3:01 PM, Ehsan Akhgari <ehsan@mozilla.com> wrote:
>
>> This issue is still pending but we need to move forward with _a_ decision
>> on the Gecko side of things, so I'm just going to assume that the spec is
>> going to get updated to make AudioNode an EventTarget and make
>> onaudioprocess an EventHandler.
>>
>> Cheers,
>>
>> --
>> Ehsan
>> <http://ehsanakhgari.org/>
>>
>
> Hi Ehsan, I had hoped we could make it be a simple Callback, but this
> doesn't seem to really affect what the JS code using the API would look
> like, so I'm not that hung up on it.  I certainly don't want to block any
> progress you're making with the OfflineAudioContext.
>
> Chris
>
>
>>
>>
>> On Thu, Jan 24, 2013 at 6:49 PM, Ehsan Akhgari <ehsan@mozilla.com> wrote:
>>
>>> Olli filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20764 a few
>>> minutes ago.  This is a bug that I hit when I was trying to implement
>>> ScriptProcessorNode.  Basically, as things stand, ScriptProcessorNode is
>>> not implementable in Gecko without the sort of hacks which WebKit seems to
>>> be going through, and we would really like to avoid that.
>>>
>>> It look like the best way to deal with this is to make AudioNode inherit
>>> from EventTarget, and make onaudioprocess an EventHandler.
>>>
>>> This is currently very high priority for the Gecko implementation since
>>> we are on the verge of landing initial audio playback support, and we need
>>> to implement ScriptProcessorNode as a way to test the ongoing work on the
>>> audio playback support.
>>>
>>> Chris, I'd appreciate if you could please take a look into this and
>>> address this issue at the spec level.  It's sort of a big change, so I
>>> don't want to just assume things and proceed on the implementation side.
>>>
>>> Thanks!
>>> --
>>> Ehsan
>>> <http://ehsanakhgari.org/>
>>>
>>
>>
>