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

[Colin Guthrie]

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