[Telepathy] Improved chandler/filter system for MC

[Xavier Claessens]

Hello,

I discussed a bit with Guillaume about Tube integration in MC/Empathy
while he was working on gtetrinet to use Empathy. I think we need more
powerful chandler/filter system in MC.

Uses cases:
----------
1) private chat client want to be started for and receive a Text channel
with an handle of type Contact and muc client wants Text channels with
handle type Room.
2) Logger application wants to receive any text channel (private and
muc), it wants to keep using the channel and let MC start the chat
client.
3) StatusIcon and ContactList wants to receive any Text channel *before*
the chat client and will tell MC when chat client can be started, like
that the they can blink the icon and wait for the user to click on it
before starting the chat program. StatusIcon and ContactList can be
separate processes, they both need to get the channel at the same time
(before chat client) and once one of them says it's ok to start the chat
the other should be warned to stop blinking.
4) GTetrinet wants to receive Tubes channels and TubeID ONLY if the
tube's service is "tetrinet-x".

Problems I see with Nokia's MC:
------------------------------
 - I can't register a chandler for a given handler+channel type. Makes
uses case 1 impossible.
 - Use case 2 is possible with a filter but the logger process needs to
be started before to register the filter and if MC exits because we go
offline the filter needs to be registered again once MC restarts (How
logger can know that?).
 - Use case 3 is not possible. We can register 2 filters but they won't
get the channel at the same time, one will be started before the other
and will wait until the user click on the icon and then MC will start
the second and wait again for the user to click on it. MC should start
all filters with the same priority at the same time and wait until one
of them says the channel can be dispatched, and MC should tell other
filters that it's being dispatched so they can stop blink the icon.
 - Use case 4 is not possible because we can't register a chandler for a
given tube service.

  I know that NMC has a plugin system that should solve most of those
problems, but I don't like the idea of writing MC plugins. Chandlers
should work with any MC implementation and a bad written chandler
shouldn't be able to make MC crash so it shouldn't be linked into MC's
daemon.

Ideas to solve that:
-------------------
  A I already said for the MC spec standardisation I think we shouldn't
separate the chandler and filter concepts, in the end both are programs
that needs to be started when a channel is created. I'll give some ideas
for a chandler system that do also filter's job. Chandler programs need
to install a .chandler file containing:
 - The DBus service of the the chandler program to be started by MC.
 - The channel type the chandler wants and/or the handle type.
 - Optionally the tube service (only if the channel type is Tubes). If
it's omitted and the channel type is Tubes MC will start the service for
all Tubes channels but not for each new TubeID created on that channel.
 - A priority number. If at some point more than one chandler should be
started, they get started in the order of priority. Each time MC waits
for the chandler to tell it's ok to dispatch before starting chandlers
with lower priority. If a chandler says it's not OK to dispatch, MC
Closes the channel and don't start other chandlers. In case of equality
MC starts all equal chandlers and waits until one of them says it's ok
to dispatch, it tells others started chandlers that the channel is being
dispatched and start the next chandler with lower priority. If the
lowest priority chandler (in most cases that's the chat-ui) tells to
dispatch and there is no remaining chandlers, MC closes the channel.

  So programs that wants to handle a channel have to provide a .chandler
file, a .service file for DBus and once it gets started it must register
a DBus object providing a standardised interface. This interface needs:
 - A "HandleChannel" method that MC will call to give the TpChan and
TpConn objects that needs to be handled, a dictionary with some
additional information for example if it's a tube chandler we'll have
("service", "tetrinet-x") and ("TubeId", 12) pairs, and a unique
ChandlerID number.
 - A "Process" method that MC will call to tell the chandler the channel
has been dispatched to a lower priority chandler (for use case 3). This
method has in parameters the same ChandlerID than the one given in
HandleChannel.
 - A "Dispatch" signal that the chandler will emit when it's OK to
dispatch. It as in parameters the ChandlerID given in HandleChannel. If
it's the StatusIcon chandler and the user says he don't want to accept
the chat, the chandler Closes the channel and don't emit the signal, MC
should listen to "Closed" signal on channels being dispatched and remove
them it they get closed.

Comments are welcome, I think we can discuss that and include it in MC's
standardised spec. I would be really happy if it could be implemented in
Nokia's MC.

Thanks,
Xavier Claessens.