On Fri, 2013-11-01 at 07:28 +0100, David Henningsson wrote: > On 11/01/2013 02:08 AM, Janos Kovacs wrote: (snip, Murphy discussion sent separately to murphy-dev) > > Colin wrote: > >> Generally, there was some degree of concern over the number of new core > >> concepts needed to support this and some questions were asked about > >> whether some parts are really internal to the routing algorithm > >> *implementation* itself, rather than the concept of routing algorithms > >> as generally supported in PA. We all agree we need a better routing > >> infrastructure, so the only question is really how many of the concepts > >> are leaks from the current Murphy-based implementation vs. genuinely > >> useful in the general case. > > > > I guess one of the concern was whether the routing group should be part of > > the core or not. > > > > Routing groups conceptually are somewhat close to the priority lists > > proposed > > by Colin originally. The implementation is quite different, however. The > > other important > > concept was to find the right list (routing group) to be used based on the > > stream properties. We proposed somewhat simpler and less generic mapping > > based > > on the media.role property + the zone.name <http://zone.name> property > > (which is new). > > To have a zone.name property (on ports? or streams? or nodes?) > intuitively sounds like a good idea, if the routing system needs this > information. > > > > > In my proposal routing groups are defined by two function, one which is > > used decide > > whether to add a node to the group and another comparision function to > > maintain > > the order of the nodes. Routing groups supposed to be defined by the > > routing module > > and consequently the routing module should provide those functions. This > > is somewhat > > more complex than the originally proposed priority list but not much. > > > > Routing groups could be implemented completely by the routing module, so > > if the verdict > > is not add core support for routing groups is completely fine IMO. > > So if this property it's something internal to the murphy module, then > I'm likely fine with that module adding/modifying a zone.name property - > but anyway; if we work in iterations, we're probably a few iterations > from having this property added, so we can sort that out the details later. > > > > > > Colin wrote: > >> I asked during the meeting about if "connection" core concept was > >> needed. This was justified that it would be needed to do things like > >> loading loopback modules, combine modules or remap modules to join > >> things up as needed. This is a reasonable justification, but after some > >> reflection I cannot see how this can be a core concept as it has to have > >> implicit knowledge of the modules. If core is loading specific modules, > >> then those modules are not really modules any more as they are needed by > >> the core. > >> > >> I guess I'm just still not super comfortable with the need to have so > >> much exposed outside of the implementation module itself. > > > > Connections, as Tanu proposed them, are somewhat new (ie. we do not have > > them in Tizen-IVI). I guess those also could be implemented in the > > routing module if > > we decide so. > > > > So if needed we could start with only nodes + some extra hooks in the core. > > However, node implementations should be added to ALSA, BT and other modules > > IMO. > > Please avoid touching the backend modules as much as you can. Ideally, > I'd like the ALSA and BT modules to just add properties (or similar > information) to indicate to the core and the routing system what it > needs to know. > > Otherwise we'll just end up copy-pasting code between different backends. > > > David wrote: > >> PA routing patches in digestible chunks. I've tried to say this > >> ever since Janos and Jaska started working on it more than a year ago, > >> but the message seems not to get through. It feels like there is a giant > >> patch set being worked on by Tanu, and having this giant patch set > >> presented all at once leads to significant risks: > >> > >> * The review will be extremely heavy. Nobody will bear to do it. > >> > >> * We might want to rethink things in the beginning of the patch series, > >> which leads to a lot of things having to be rewritten. > > > > This is a valid concern. From the comments/judgements I see that we went > > too far already ... The plan was to get a working proto and then break > > it into smaller > > understandable units that could be reviewed. > > > > This is mostly my fault, since I did not want to propose/review > > something that might > > turn out inadequate in later phases. I hope Tanu will also comment on > > this :) > > That's always a balance, of course, and I understand this point of view > too. In my experience, to try to keep things simple (as few concepts as > possible) and then try to cover the corner cases by either tweaking the > existing concepts, adding a special property or something like that, is > more likely to be maintainable, compared to trying to think of all > corner cases and come up with logical model that covers them all. > (Because such a logical model will be very complex in itself and is > likely to have its own set of corner cases anyway.) YMMV.
