[pulseaudio-discuss] GSoC ideas

[David Henningsson]

On 04/27/2013 05:12 AM, Arun Raghavan wrote:
> 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).

Well, that really well-supported language would be C, if that's what the 
API was in.
Also, we could make a C header that was clean enough for most of the 
auto-binding-generator tools to be able to process, if that helps.

> 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.

I don't know Lua much, but for me it would definitely be harder, not 
easier, because

  1) I would have to learn a new language. And while learning the basics 
of a language is not that hard, finding and understanding all its quirks 
in its implementations is really time consuming (and that's what you 
need in order to track down bugs).

  2) I would have one more dependency on PulseAudio, that needs to be 
maintained, a potential source of bugs, version transitions, etc.

  3) There is always an efficiency cost when switching between 
languages, in this case, jumping back and forth between the Lua 
interpreter and the PulseAudio compiled code.

  4) If I write a module, I have access to the core and all sub-objects. 
We would typically choose some subset if we were to write some lua 
bindings. (If we were to do a stable C API for modules, that would 
probably also be some subset, so this argument is more a comparison to 
the current situation.)


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic