On Tue, 2013-08-06 at 14:42 +0200, David Henningsson wrote: > On 08/06/2013 02:30 PM, Tanu Kaskinen wrote: > > On Tue, 2013-08-06 at 13:26 +0200, David Henningsson wrote: > >> On 08/05/2013 01:37 PM, Tanu Kaskinen wrote: > >>> On Wed, 2013-07-17 at 12:26 +0200, David Henningsson wrote: > >>>> On 07/17/2013 11:22 AM, Tanu Kaskinen wrote: > >>>>> On Wed, 2013-07-17 at 09:27 +0200, David Henningsson wrote: > >>>>>> On 07/16/2013 03:20 PM, Tanu Kaskinen wrote: > >>>>>>> What operations do you mean? Moving or removing a default connection is > >>>>>>> not supported as such, but if the client tries that anyway, we can > >>>>>>> implicitly convert the connection to an explicit one and disable default > >>>>>>> connections, or we can require the client to do these operations > >>>>>>> explicitly, but I think the latter would be too inconvenient for the > >>>>>>> client. > >>>>>> > >>>>>> Ok, I think I didn't read the proposal well enough. Having done that, I > >>>>>> understand that you're suggesting a global switch "default connections > >>>>>> on/off" only. Or is it a per-node switch? > >>>>> > >>>>> It is a per-node switch. > >>>>> > >>>>>> I have another idea that might be worth considering: how about that the > >>>>>> "explicit" layer can both enable and disable connections? So that there > >>>>>> could be a default connection between A and B, but there is also some > >>>>>> sort of explicit override that disables it. This would be more flexible > >>>>>> than a more global on/off switch. > >>>>> > >>>>> I'm not sure what you mean. Do you perhaps mean that the default > >>>>> connection on/off switch should be per-node (which it already is in my > >>>>> proposal), or that it should be per-connection (so that if there are > >>>>> multiple default from node A, it's possible to disable only a subset of > >>>>> those)? > >>>>> > >>>>> I didn't make make it possible to disable individual default > >>>>> connections, because I had a feeling that it would have very messy > >>>>> semantics. If default connection from A to B is disabled, what is the > >>>>> routing code supposed to do when conditions change and the default > >>>>> routing is re-evaluated? Can it ever reactivate the connection between A > >>>>> and B again? Is the per-connection disabling handled as a blacklist of > >>>>> connections that must never be automatically activated? > >>>> > >>>> If the A -> B route is explicitly_disabled, that overrides any default > >>>> connections the routing system tries to make. > >>> > >>> What is the use case for explicitly disabled connections? I'll assume > >>> here that your idea was to allow moving a default connection elsewhere > >>> (making the connection explicit in the process) without disabling all > >>> default connections for the node. > >>> > >>> When the user moves a default connection, the routing system obviously > >>> shouldn't immediately create another default connection elsewhere to > >>> replace the disabled connection. > >>> > >>> On the other hand, if the routing system doesn't create replacement > >>> connections, then that results in weird behaviour. Let's say that > >>> there's a default connection A -> B, and the user moves the connection > >>> to A -> C. Then B disappears. The routing changes its opinion of the > >>> best available routing for A, which might be D. So removing node B > >>> resulted in audio suddenly appearing in node D, even though nothing was > >>> playing to B. > >>> > >> > >> Assume your example of a default connection A -> B which the user > >> changes into A -> C, by adding an explicit A -> C connection. Without > >> some sort of explicitly_disabled blacklist that would then include A -> > >> B, the routing system would be free to route A to *both* B and C. > > > > My solution is that the application disables the default routing > > altogether for A, if it doesn't want to have the default connection A -> > > B. It seems to me that this causes fewer surprises than the blacklisting > > approach. > > > >> Whether this is implemented as a bool flag or as a separate blacklist is > >> an implementation detail, but a bool flag just seemed simpler and faster > >> to me, than having to look in several lists to figure out whether a > >> connection exists or not. > > > > You don't need to look in several lists to figure out whether a > > connection exists or not. If we have connection objects, which I think > > we both want to have, it's enough to get the list all connections and > > see whether a particular connection is included in that list. > > > > Okay, so let me see if I understand this right. You propose that you can > add explicit connections between two specified nodes, but blacklisting > default connections have to be done on a node wide level (rather than > per connection). > > That sounds interesting, as it would be more resilient towards nodes > appearing and disappearing later on. > I think that blacklisting would have to be two booleans per node though, > one for outgoing connections and one for incoming. And a connection > cannot exist if it is blocked on *either* side, rather than both sides. > Does that make sense? My plan has so far been to only disable outgoing default connections, but if there's need for it, I don't see any problem with adding another bool for disabling incoming default connections. Do you have a use case? -- Tanu
