[Telepathy] MissionControl's spec

[Xavier Claessens]

On dim, 2007-10-21 at 23:29 +0200, Xavier Claessens wrote:
> Hi,
> 
> I opened a darcs branch to add MissionControl's spec into
> telepathy-spec[1]. You can see generated html [2]
(...)
> [1] http://projects.collabora.co.uk/~monkey/telepathy-spec-mc/
> [2] http://projects.collabora.co.uk/~xclaesse/spec.html

Darcs branch and html spec updated with new functions: RegisterChandler
and GetInfo. The goal of those functions is to be able to add chandlers
at runtime without installing .chandler nor .service files. This is to
replace current filters system in NMC. I also updated the spec with
telepathy-spec HEAD.

Remaining questions for the spec:
1) We should define some common priority values like
   pre-process=4000
   notify=3000
   handler=2000
   post-process=1000.

NMC has those defined:
typedef enum {
	MC_FILTER_PRIORITY_CRITICAL = 0,
	MC_FILTER_PRIORITY_SYSTEM = 1000,
	MC_FILTER_PRIORITY_NOTICE = 2000,
	MC_FILTER_PRIORITY_DIALOG = 3000,
	MC_FILTER_PRIORITY_MONITOR = 4000
} McFilterPriority;

What types and values should we define in the spec?

2) Should Priority be signed integer to allow negative values?

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.

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?

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.

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?

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.

That's all issues I see for now. I would appreciate some more deep
review from Nokia/Decibel/Telepathy guys.

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

Xavier Claessens.