[Telepathy] Improved chandler/filter system for MC

[Xavier Claessens]

I modified MC spec with my proposed Chandler system. You can see it there:
http://projects.collabora.co.uk/~xclaesse/mc/doc.html
I modified .chandler file format and
org.freedesktop.Telepathy.MissionControl.ChannelHandler interface.

Xavier Claessens

2007/10/9, Xavier Claessens <xclaesse at gmail.com>:
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/telepathy/attachments/20071011/e556548a/attachment.htm