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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
