On Fri, 2013-04-26 at 16:40 +0200, David Henningsson wrote: [...] > >>>> - Simplified way for scripting pulseaudio and doing basic event > >>>> handling. Normal (power) user should script their soundsystem. > >>> > >>> I believe there's general agreement that we want Lua scripting in > >>> PulseAudio. I think this would be a very good GSoC project. > >> > >> Eh? I've never heard of adding Lua scripting before, > > > > Hmm, it was discussed briefly in PulseConf (at downstairs, before the > > event officially started). My recollection is that Janos brought up the > > topic, and me and Arun ended up agreeing that it would be a good thing > > to have (for example, it makes it easier for users to implement whatever > > strange policies they may want to have). You apparently weren't present, > > I'm not sure about Colin. > > > > For what it's worth, I remember Lua scripting is also something that > > Lennart wanted to do for a long time, but never got around to it. > > > >> and I'm very much > >> against adding yet another dependency to PulseAudio without a very very > >> VERY good reason. > >> > >> That said; it looks like liblua 5.1 is part of ubuntu-desktop already, > >> so that particular dependency would not cause too much trouble in > >> desktop scenarios much, but it would still bloat embedded scenarios, > >> which is bad enough. > > > > So make it an optional feature, problem solved? > > Well, it depends. If we start to use Lua ourselves, and ship Lua scripts > as our recommended way to do something, it's optional in theory but not > in practice. > > >> Or, to look at this from another angle - what's wrong with shell > >> scripting? What things are there that you can't do with shell scripting > >> today that Lua would solve? > > > > Executing code synchronously in a hook is one thing that will never be > > available via shell scripting. > > > > That said, Alexander's original idea was "simplified way for scripting > > pulseaudio and doing basic event handling". That doesn't necessarily > > mean server-side scripting. I don't think we currently provide very nice > > tools for client-side scripting either, so e.g. a Python library would > > be one possible project. > > It seems to me that in either case (client-side or server-side), this > should be provided as some type of C API, rather than messing with a > different language. Then people can implement their stuff in what > language they want (since C bindings are available for most common > languages). Practically speaking, this does not work. You end up with a large set of poorly supported bindings, instead of one really well-support language (see: GNOME). I think having an embedded scripting language makes a lot of sense (Lua is a popular choice for embedded interpreters because it's light-weight). We repeatedly run into embedded cases where people need to write their custom policy modules. Having a mechanism to script this instead of writing C would make things easier. -- Arun
