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

[Tanu Kaskinen]

On Mon, 2011-04-18 at 11:35 +0300, Colin Guthrie wrote:
> > 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?

I'm not sure what you exactly mean. This is what I had in mind for the
stuff that needs to be added to the core, I guess it's pretty close to
what you described:

For publishing APIs:

/* Returns a negative error code if the extra api is already registered. */
int pa_extra_api_register(const char *name, void *api);

void pa_extra_api_unregister(const_char *name);

For consuming APIs:

/* Returns the currently registered api object,
 * or NULL if the api isn't registered right now. */
void *pa_extra_api_get(const char *name);

Additionally, there would be a couple of hooks defined for getting
notifications about APIs getting registered and unregistered.

The "api object" would be a struct with function pointers. The API
provider would create instances of that struct and provide the function
implementation. The API consumer would talk to the provider using those
function pointers. The api object header could be located in
src/extra_apis - that would make the api not directly dependent on a
particular module. I don't really have real-world requirements for
"generic" apis that could be provided by multiple modules, but I can't
see any costs either for this genericity, other than some minimal added
clutter in the src directory.

I've been using the term "extra api" here. I don't think it's the
greatest name in the world, but that's the best I could think of. I'd
like "extension" more, but that word is already used for other purposes.

-- 
Tanu