[Telepathy] MissionControl's spec

Alberto Mardegan mardy at users.sourceforge.net
Wed Dec 19 02:31:12 PST 2007


ext Xavier Claessens wrote:
> Only for one method or do we have more to put in Dispatcher? I we go for
> a Dispatcher we'll have one object with AccountManager and Dispatcher
> interfaces, right?

I think it belongs to a different object.

> I'm not sure it's a useful feature but what I had in mind is to be able
> to register a Chandler without having it running. The chandler could
> install a .service file and another program could call RegisterChandler
> for it. and MC will start the chandler when calling GetInfo or
> HandleChannel.

It seems so complex...

> That gives me an idea:
> What if all chandlers need to be registered? When I start Empathy it
> registers empathy's chat/voip/etc chandlers. If kopette is started it
> will registers kopette's chandlers. That solves the problem of choosing
> the right chandler without the need of user configuration. With that
> solution .chandler files or used only to cache information, like that MC
> don't have to call GetInfo on each registered chandler. We can add a
> flag in chandler "StartEvenIfNotRegistered" for chandlers that does not
> depend on a particular client, in that case it's user's (or
> distribution's packager) responsibility to not install 2 conflicting
> chandlers.

Mmmm... Can you provide an example of a case where this implementation 
would be useful?
Thinking over my last proposition, that is making the installation of a 
.chandler file mandatory, I thought it would be best to remove the DBus 
GetInfo/RegisterChandler APIs completely, unless we can think of some 
use case where they would actually be needed.
The only method that would be useful for the Dispatcher is a Reload() 
operation, that re-scans the .chandler directories.

> The only big difference between presets and NMC's profiles in my draft
> is the ability to create an account without specifying a
> profile/presets. Clients/MC must be able to create an account using only
> information provided by the CM itself.

Makes sense.

> For example if MyCompany provides a SIP service that needs some
> customised values I can put a .presets file in my webpage that the user
> have to save in ~/.local/something. The presets file will looks like:
> 
> [Presets]
> Manager = sofiasip
> Protocol = sip
> Default-registar = registar.my-company.com
> [UI]
> IconBase64 = HGD12HGFD4HGFD1 --> MyCompany's logo, non-free data
> DisplayName[en] = "MyCompany's SIP service"
> Description[en] = "MyCompany provides a cheap service for calling any
> phone number for only $0.20 per minute"
> 
> I'm not sure if UI section have to be parsed by MC to know what to
> return in GetDisplayName and GetIconName in Account interface or if
> those functions returns NULL and the client is responsible to look in
> presets for a default value.

I think that those APIs in the Account interface are for retrieving the 
display name (and icon) for that account, not for the service. These 
data will be stored in the .presets files and be accessed directly by 
the clients.
In facts, I don't think that the icon belongs to the Account interface;
we already have the avatar, that's probably good enough to be used as icon.
On a side note, MC doesn't know anything about locale.

> If we want base64 icon in presets Account's API will need one more
> function GetIconData() to be used by client if GetIconName returns an
> empty name.

Brrr... the more I think of it, the more I'd like to have this icon 
stuff removed from the API. :-)

Ciao,
   Alberto

-- 
http://www.mardy.it <-- Geek in un lingua international!


More information about the Telepathy mailing list