[pulseaudio-discuss] GSoC ideas

[Arun Raghavan]

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