[Telepathy] MissionControl's spec

[Alberto Mardegan]

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

> 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.

> 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. :-)

> 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?

> 7) Presets files are mainly (only?) useful preconfigured service for
> companies. Gtalk presets is not useful anymore since gabble can detect
> all param magically now, or maybe just a dumb presets file for users
> that does not know gtalk==jabber. The idea is a SIP provider can ship
> a .presets file with all default parameters to work outofthebox with
> their service. Companies will surely have non-free icons that we won't
> be able to distribute. What about adding an optional base64-encoded icon
> data in the .presets file? Like that a single file downloaded from the
> companie's website contains everything needed to display the service to
> the user.

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?

> I saw Mardy started implementing the new spec in a NMC branch. What's
> the status of that work? I think you should use telepathy-glib
> auto-generated code to implement it. Client-side library won't be useful
> anymore since telepathy-glib will provide auto-generated client API and
> some helper objects could be added in tp-glib too. So I'm not sure it's
> easier to fix current NMC or to start one from scratch...

I'm just working on the server side, and implementing the DBus API is 
not that hard with dbus-binding-tool; would telepathy-glib make that 
even easier?
For client side, I'll surely consider it.

About your first question, I'm working on the AccountManager and Account 
objects, and it seems to me that it won't take too much time to complete 
them. I'm a bit more hesitant about channel handlers and filters, it 
seems we still have something to discuss about them.

Ciao,
   Alberto

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