On Fri, 2013-11-01 at 03:08 +0200, 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 property (which is new). > > 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. > > 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. > > 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 > :) > > br > -janos-
