'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/]
