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

[Colin Guthrie]

'Twas brillig, and Tanu Kaskinen at 06/04/11 16:23 did gyre and gimble:
> On Wed, 2011-04-06 at 14:23 +0100, Colin Guthrie wrote:
>> 'Twas brillig, and Tanu Kaskinen at 06/04/11 12:33 did gyre and gimble:
>>> +/* This is a shared singleton object, currently used by Meego's voice and
>>> + * policy enforcement modules. The purpose of the object is just to maintain
>>> + * a boolean state of "call is active" or "call is not active", and to provide
>>> + * notification hooks for tracking state changes. So one module will be setting
>>> + * the state (the voice module) and one or more modules will follow the state
>>> + * through the hooks (the policy enforcement module). */
>>
>> Could I use this approach to, for example, extend module-stream-restore
>> and module-device-restore, to save particular keys in a stream, or
>> device proplist?
> <snip>
> 
> I don't see any reason why you couldn't.

Just realised I quoted totally the wrong bit there.... I meant to quote:

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


Which probably makes my comments seem a little more sane :D

Do you have any specific requirements for this inter-module IPC? Do we
just need a hook system with random data pointer + userdata? The random
data pointer would be specific to the caller/callee pair and the
userdata would be as per usual. Anything more specific than that needed?

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]