[Telepathy] Proposed standard MC API

[Alberto Mardegan]

ext Sjoerd Simons wrote:
> So it looks to me as if you to always specify this dir for any chandlers to be
> found at all.. For your problem, which the MC exiting and losing it's state
> info: Why not just listen on dbus for when the MC reappears on the bus and
> reset it's state the way you want it.

Well, it is more work for the app, and if MC has been started to handle 
a channel, it might be already too late to change the chandlers at that 
point.

> Which makes you fall into the trap of deciding which chandler is best. If i got
> say 3 telepathy clients installed (GNOME, KDE, something else?).. Each will
> install their chandlers, so now a text channel comes in.... Which one should be
> started by the MC?

Tricky question :-)

> By explicitely telling the MC over dbus what the chandlers are (or in which dir
> they are) for you session your basically working around this problem.

Yes, that would solve the problem. Another approach that just came to 
mind (and therefore it could be totally broken) is to have chandler 
paths indexed by a keyword, like in a hash table. There will be an API 
similar to this:

  SetChannelHandlerDir (s:key, s:directory) -> nothing

which will set/add a _persistent_ chandler dir (that is, it will be 
remembered across MC restarts); if called with a "key" that has already 
some path associated to it, this path will be overwritten.
Use case is:

SetChannelHandlerDir ("system", "/usr/share/telepathy/mission-control/")
[bad example, I think a standard XDG path should be "hardcoded" into MC, 
so no need usually to add a system dir]

Then when Gnome starts someone (the presence applet, maybe) will call
SetChannelHandlerDir ("desktop", 
"/usr/share/gnome/telepathy/mission-control/")

And of course KDE will set a different path for the "desktop" key, 
overriding that one.

> Now i start up some magicall sip specific (branded?) client.. Which wants to
> take over (all?) sip calls from empathy. And thus wants to install it's own
> chander that _overrides_ the current ones for SIP streamed media channels.
> 
> Will this work with the current proposed API (and if so how).

No, or I can't just think of it. A "Priority" field in the .chandler 
files would also not be the best solution, since it cannot guarantee 
that there won't be channel handlers with a higher priority; anyway, I'd 
like the user to be able to select the priorities himself, so that if he 
is using gnome and he doesn't like empathy (poor guy), he can choose to 
have the KDE client as default handler.
(which renders my proposal above quite pointless, but maybe someone will 
come out with an improved version :-) )

> And a final remark:
> 
> org.freedesktop.Telepathy.MissionControl.ChannelHandler has a signal to notify
> the MC that it can pass the channel to the next handler. Shouldn't there also
> be a signal to notify that it shouldn't _ever_ be passed to the next handler ?

If it doesn't pass the channel, it will just keep it and close it when 
it is done with it; the signal you propose would let MC free some 
resources in advance, but I'm not sure that this is worth adding it.

Ciao,
   Alberto

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