[Telepathy] MissionControl's spec

[Xavier Claessens]

Le lundi 17 décembre 2007 à 17:25 +0200, Alberto Mardegan a écrit :
> ext Xavier Claessens wrote:
> > 3) RegisterChandler is on the AccountManager object because that's the
> > object we are sure MC is always exporting when it's running. Chandlers
> > can handle channels regardless of the account it comes from, so we can't
> > put this method in Account interface. But I'm not sure registering a
> > chandler is part of the account management... Maybe we should rename
> > org.freedesktop.Telepathy.MissionControl.AccountManager to
> > org.freedesktop.Telepathy.MissionControl, this object will be
> > responsible of all operations on the MC itself.
> 
> Maybe we can have it on a different object, that is 
> org.freedesktop.Telepathy.MissionControl.Dispatcher

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?

> > 4) If MC leaves or crash and gets restarted it will forget about all
> > chandlers registered using RegisterChandler. That's a problem NMC has
> > with filters too. Should MC save BusName and ObjectPath of all
> > registered chandlers on file to restore if restarted, or should I impose
> > in the spec a pattern for chandlers BusName and ObjectPath like that MC
> > can find them using ListNames?
> 
> If we go for the latter, then maybe we don't even need the 
> RegisterChandler function anymore, since MC would be also listening to 
> NameOwnerChanged.

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.

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.

> > 5) How to choose between multiple IM programs? Imagine we have kopette
> > and Empathy both installed and both having their chat chandler waiting
> > for any Text channel. How MC will decide which UI to start? I think we
> > need a file somewhere in $XDG_DATA_HOME that blacklist some chandlers to
> > disable them. Like that we can build an application that shows all
> > chandlers to the user and he can decide to disable kopette chandlers for
> > example. That means we have to add some more information in .chandler
> > files to give to the user translated name/description of the chandler.
> 
> Maybe we could have an optional field in the .chandler files that lists 
> the environment variables that must be set for using this filter. For 
> instance, Empathy would be started only if GNOME_DESKTOP_SESSION_ID is set.
> 
> Or there could be a field with the name of a file whose existence must 
> be verified prior to starting the CH.
> This could actually make the RegisterChandler/GetInfo API useless (well, 
> in that case maybe instead of a file we could have a flag in the 
> .chandler file that means "use this CH only if its bus name is already 
> alive"). The more I think about it, the more I like the idea. :-)

That's a possibility, yes.

> > 6) We need translated name/description in presets files too. How do we
> > translate for files? Using the same system than desktop files I suppose?
> 
> I thought that .presets where only for specifying default CM parameters; 
> what name/description are you proposing?
(...)
> Mmmm... so you want the .presets files to contain UI-specific data, too?
> In that case, I think the .presets files should have different sections, 
> one for the CM parameters, and one (or more) for the UIs. Since 
> different UIs might need different data (and icon size), there could 
> also be a different section for every different UI.
> In any case, I think that MC should not even try to parse these data, right?

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.

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.

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.

Xavier Claessens.