'Twas brillig, and Tanu Kaskinen at 20/04/11 11:54 did gyre and gimble: > 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(). Ahh I get what you mean :) Yeah this all makes sense. Thanks for clarifying :) >>> 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. OK, so the manager object is separate but kept in the core? Seems fine by me to keep things neatly separated. I thinking of taking a pop at this at some point soon (if you don't beat me to it), so can we decide on the name now? Anyone got any better naming suggestions? pa_imc_manager_* (Pro: short, Con: "Inter Module Comms" cryptic) pa_extra_api_manager_* (Pro: clear, Con: long, Extension vs. Extra which is which and for what purpose?) pa_xapi_manager_* (Pro: short, Con: might be confused with X11) pa_mxapi_manager_* (Pro: quite short, Con: "Module eXtension API" but still quite cryptic) I'm not really blown away by any of them :s 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/]
