Re: The issue of ScriptProcessorNode not being an EventTarget

On Tue, Mar 5, 2013 at 10:11 AM, Chris Rogers <crogers@google.com> wrote:

>
>
> 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)
>

I prefer option 2. More code will be written in future than has been
written to date.

This should not be "serious": User agents can deprecate it strategically by
aliasing the old property name, deprecation warnings (perhaps audible
ones!), then removal.


> 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/>
>>>>
>>>
>>>
>>
>