On Wed, 2011-04-20 at 11:36 +0300, Colin Guthrie wrote: > > The api object header could be located in > > src/extra_apis - that would make the api not directly dependent on a > > particular module. > > If the API is not dependant on a particular module, what code calls > pa_extra_api_register? I'd be happy enough defining this extra API as an > "IMC" (c.f. IPC) system and thus make it very much tied to modules. Hmm... did you get the impression that these apis would not necessarily be tied to any modules at all? That was not the idea - the apis would be implemented always by modules, but not necessarily by any particular module. For example, if there was an api for getting the current call state, it could be implemented by multiple modules, each of which would use different logic for determining whether a call is active or not. The modules would of course conflict with each other, so they could not be loaded at the same time. This would be handled by pa_extra_api_register() - only one module could have the api registered at any given time, the other modules would get an error when they try to call pa_extra_api_register(). > > 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. > > Yeah extension is already in use for protocol extensions I guess. > > How about pa_imc_*? (for inter-module comms) or is that perhaps too > cryptic? Yeah, it's cryptic, but it's also shorter. And "extra api" isn't an obvious name either. I'm not sure which I like more. Probably imc. Regarding function names, they will actually have form pa_imc_manager_* or pa_extra_api_manager_* if I get to decide... The functions can be "methods" of either some manager object or pa_core. If they're implemented directly by pa_core, then the prefix will of course be pa_core_, but I'd prefer having a separate manager object. -- Tanu
