[pulseaudio-discuss] Edinburgh Murphy meeting notes

[Tanu Kaskinen]

On Thu, 2013-10-31 at 10:47 +0000, Colin Guthrie wrote:
> 'Twas brillig, and Tanu Kaskinen at 28/10/13 19:55 did gyre and gimble:
> > On Mon, 2013-10-28 at 17:50 +0000, Colin Guthrie wrote:
> >> Hi Guys,
> >>
> >> I made a few notes about this meeting. Feel free to add CC's as you see
> >> appropriate. Also please feel free to correct my version of events just
> >> in case I've put something down incorrectly.
> > 
> > Awesome, thanks for the notes! Any objections to sending this to the
> > pulseaudio-discuss and murphy-dev lists too?
> 
> Of course, no problem at all.
> 
> >> 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 got the criticism about routing groups - if there are other concepts
> > that you find questionable, please let me know.
> 
> I think this is more just a "general worry". There are a lot of new core
> concepts being introduced to achieve the end result and from the queries
> and questions asked, I got the impression that the people with PA
> background present were somewhat nervous about this, but perhaps I
> picked up and generalised things too much?
> 
> At the moment, the routing is very simple. Too simple (obviously!) but
> at least it keeps it manageable and understandable right now. I guess my
> main concern is that it will turn even very simple routing
> configurations into a very complex beast.
> 
> 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.
> 
> Again, as I've not done much PA dev for a while now, my opinion should
> carry little weight, but after more reflection, I do feel the core
> changes should be kept as limited as possible, with the minimum of hooks
> and interfaces needed and the rest kept as private as possible to the
> implementation itself.
> 
> Again, just my opinion, so feel free to ignore it :)
> 
> Col