W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

Re: [Bug 17793] New: AudioNode.disconnect() needs to be able to disconnect only one connection

From: Peter van der Noord <peterdunord@gmail.com>
Date: Thu, 19 Jul 2012 20:31:13 +0200
Message-Id: <559AB72D-87BB-4D4D-AB0A-82A36872C0C4@gmail.com>
Cc: "public-audio@w3.org" <public-audio@w3.org>
To: Chris Wilson <cwilso@google.com>
I did some more thinking about this part:

> On Wed, Jul 18, 2012 at 2:24 AM, Peter van der Noord <peterdunord@gmail.com> wrote:
> Ok, that's clear. But going back to what got us here, the suggested disconnect function:
>  void disconnect(in [Optional] AudioNode destination, in [Optional]
> > unsigned long output = 0)
> >             raises(DOMException); 
> ...doesnt seem like it can unambiguously handle all cases, 
> nodeA.connect(nodeB, 0)    -> A out#0 to B in#0
> nodeA.connect(nodeB, 1)    -> A out#0 to B in #1
> Supplying an output and a destinationnode is not enough to pinpoint any of the two connections, you will *have* to supply the destination's input index as well if you want to remove one (or do i think i'm understanding this, while in fact i am not)
> Heh.  Right you are, you would in fact have to (potentially) supply the destination's input 

I wanted to add that, in my opinion, the method should raise an exception when it's not unambigously clear what to disconnect. But, thinking further...this can't be done.

Take the above connections as an example, and this most recently suggested disconnect method:

node.disconnect(node = null, outputindex = 0, inputindex = 0) with all parameters optional.

Now, let's say i want to remove the connection i made on the second line (A out#0 to B in#1). Let's also assume that i somehow forgot that the other connection going out of out#0 existed. I'd do:

nodeA.disconnect(nodeB, 0);

My thought was raising an exception here would be nice: "hey, you want to remove a connection from an output, but there are more connections there so i don't know which one to remove."

But, since the optional third parameter (which defines the input#) defaults to 0, there is no way to throw an exception, because the other connection will simply be removed.

And the method would react even differently when the first connection wasnt connected to input #0 but to #2. Again i'm forgetting there are two outgoing connections on output #0:

nodeA.disconnect(nodeB, 0);

Third parameter not supplied, defaults to 0, probably gives an error because there's nothing there on input #0.

The fact that all params are optional doesnt help in my opinion, it leaves a lot of room for unnoticable mistakes. Does anyone else see this as a problem, or am i the only one? :)


Received on Thursday, 19 July 2012 18:31:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:10 UTC