[pulseaudio-discuss] [PATCH] call-state-tracker: New component.

[Tanu Kaskinen]

On Wed, 2011-04-06 at 00:57 +0300, Maarten Bosmans wrote:
> What are the users of this state tracker? Is it only some out-of-tree
> Meego modules? Are you planning to submit those too? At least a
> snippet of how it should be used would be nice.

The users are mentioned in call-state-tracker.h. I guess I should have
said "See call-state-tracker.h for details." in the commit message.
(Colin, feel free to add that sentence in the commit message, if you
decide to accept this patch.) So yes, only some out-of-tree Meego
modules use the call state tracker. About upstreaming those - there are
no concrete plans that I'm aware of. I guess the only issue is that we
are not confident that the code is clean enough...

> If I read correctly it is a global boolean state tracker that is a
> thin wrapper around pa_shared. Is it possible to add the update-hook
> capability pa_shared and just use that from the modules. It would
> probably mean a couple of lines more in the modules, but the
> functionality in pulsecore would be more generic and more widely
> usable then.

Adding an update hook to pa_shared would cover part of this, but it
wouldn't take care of the lifecycle management. pa_shared must be empty
when the daemon is shut down. The two modules that use the call state
tracker can (at least in theory) be loaded completely independently and
in any order. How should they take care of removing the item from
pa_shared? The most sensible way that I can see is reference counting,
and implementing that is easiest to do by having the code in
libpulsecore. I'd argue this is not in any significant way different
from what is done also by protocol-native.c and protocol-dbus.c etc.

Anyway, I do agree that it's not nice to clutter pulsecore with these
inter-module libraries. I sent the following message as a reply to the
patch yesterday, but from a wrong email address, so it got stuck in the
moderation queue:

"""
This is sort of ugly - I think pulsecore isn't really the right place
for this kind of things. But take it if you don't think it's too ugly.
We depend on this patch on Maemo (and Meego too, I believe).

I'd be interested in implementing at some point (no promises or
timelines) a small framework for making inter-module communication
easier, or at least cleaner (this kind of hacks in pulsecore are
actually very easy to work with, but clean they are not). The main
motivation for this would be ripping out the dbus stuff from
module-stream-restore. The dbus API implementation in
module-stream-restore.c takes about a half of the whole file, which
makes reading the stream-restore code more difficult than it should be.
I'd like to keep the dbus interface implementation in
module-dbus-protocol only. For this to be possible, there would need to
be some way for the modules to talk to each other. It could be solved in
a similar way as this call-state-tracker is done, but I'd prefer a
generic framework that modules could use to publish "extra APIs" that
other modules can then use.
"""

-- 
Tanu