[Telepathy] Review of MissionControl spec

[Xavier Claessens]

smcv will start to review the proposed MissionControl spec. Current
draft:
darcs: http://monkey.collabora.co.uk/telepathy-spec-mc/ 
html: http://people.collabora.co.uk/~xclaesse/spec.html

Here I summarised pending questions and propositions from previous
threads and I added some points I had still in mind.

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? Should Priority be
signed integer to allow negative values? I think defining spaced values
(1000, 2000, etc) is good to let chandlers insert themself pre/post any
other chandler.

2) 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... I think we should add a
Chandler iface on /org/freedesktop/Telepathy/MissionControl object.

3) 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. The spec should impose a format to BusName and
ObjectPath, like that MC can find them using ListNames and get info
about them using GetInfo.

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

Propositions:
 - Blacklist chandlers that shouldn't be used.
 - Optional field in chandlers to enable/disable it.
 - We could have an optional field in the .chandler files that lists the
environment variables that must be set for using this chandler. For
instance, Empathy would be started only if GNOME_DESKTOP_SESSION_ID is
set.
 - 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").

5) Make clear in the spec that GetParamaters only return values that
differ from default value from CM/presets. To get the final list of
parameters and values, MC and clients should 1) read .manager file from
CM, 2) override values using presets if any, 3) override values with
those stored by MC using GetParameters.

6) MC could face some errors while processing channels, writing account
configs, etc. Maybe we need a Error signal somewhere to report them.

7) Maybe we could add RequestChannelWithStringHandle, like that we can
initiate, for example, a chat with a contact even if our account is
offline. MC will put account to default presence magically. Btw there is
an error in MC draft spec of RequestChannel: it shouldn't say that that
call puts account online because the call wants a handle that can only
be provided if the account is online.

8) For some channels client could have some work to do before
dispatching it. For example if I right-click on the contact list to
start a audio/video call with a contact, Empathy creates a StreamedMedia
channel with handle=0 and handle_type=None and adds the selected contact
in the group interface of the channel. In that case MC should start
dispatching the channel only once the contact is remote-pending on the
channel.

Propositions:
 - Remove RequestChannel from MC spec, clients will have to call
RequestChannel directly from CM and if it set supress_handler=true
client is repsonsible to call DispatchChannel(bus_name, object_path)
from MC spec once the channel is ready to dispatch. With that solution
we can't use RequestChannelWithStringHandle to create a channel on
offline account to set it online magically.
 - Client should register a high priority chandler to catch the channel
and add the contact to the group iface.

9) A chandler should be able to stop MC from dispatching the channel.
The spec should say that if the chandler don't want lower priority
chandlers to be started it should call Close() on the channel.

10) We need a ParametersUnset signal in response to UnsetParameters
call.

11) We should tell how to translate DisplayName in presets files,
probably the same way than desktop files.

12) In preset file format we could:
 - Add a optional and translated description field
 - Move default values to a separate group to use the param name as key
instead of Default-$param.

13) I completely removed icons from the spec. Atm the client is
repsonsible to choose and install on the system an icon for
accounts/presets depending on the protocol. I think we could add an
optional IconName field in presets file, that icon name must follow the
icon naming spec. The machinery to easily install .presets file and the
corresponding icon is out of the scope of MC spec, they can be manually
copied to ~/.local/share. Displaying the presets's icon or a default
icon based on the protocol or nothing is client's choice.

Xavier Claessens.