[Telepathy] Proposed standard MC API

[Sjoerd Simons]

On Tue, Aug 14, 2007 at 02:21:00PM +0200, Xavier Claessens wrote:
> 
> Le mardi 14 août 2007 à 13:53 +0200, Sjoerd Simons a écrit :
> > On Fri, Aug 10, 2007 at 03:54:40PM +0100, George Wright wrote:
> > > Again, the online specification has been updated:
> > > 
> > > http://projects.collabora.co.uk/~george/MissionControlSpec.html
> > > 
> > > Changes:
> > > - Initial Channel Handler API.
> > 
> >   What seems a little bit strange to me. The channel handlers are defined by a
> >   set of files on the filesystem, which you basically point the MC to (look in
> >   this dir, there are my prefered chandlers)
> > 
> >   Is there any reasons to not just send the information in the chandler
> >   files over dbus to the MC?
> > 
> >   Sjoerd
> 
> If MC exits but not the client that registered the chandler (that
> happens when you set presence to offline) you want MC to get your
> chandler again we it restarts. That's a problem I have with NMC and
> filters atm. When MC starts it should scan the bus to detect all
> chandler objects and call a method on them like GetInfo() to get all
> information about that handler and register it again.

I might be misunderstanding the proposed spec. But it doesn't indicate a
default dir for chandlers and has a function SetSearchPath:
  Sets the search path to find the .chandler files which define the Channel
  Handlers.

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.

> Another problem is that the UI that register a chandler is not running
> when there is no channel to handle. It get launched by DBus when MC call
> a method on the service provided by the chandler... So the chandler
> can't register itself through DBus if it's not running at first. That's
> why we have a file that MC read to know on which DBus object it should
> call to launch the chandler service.

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?

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.

In practise i think there will always be a managing entity in the users
session (for example a presence applet). So i don't think this is really an
issue.

An extra question for the proposed API:

Say i'm a happy empathy user and this being the future, so assume empathy does
supports voip. And there is thus a chandler registered for VOIP by empathy.

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


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 ?

  Sjoerd
-- 
You can't mend a wristwatch while falling from an airplane.