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
