[Telepathy] Proposed standard MC API

[Xavier Claessens]

Le mercredi 08 août 2007 à 08:25 +0300, Alberto Mardegan a écrit :
> ext Xavier Claessens wrote:
> > Is there something about chandler/filters in the standard yet? I'm
> > facing a problem with the filter system I pushed into NMC: Empathy
> > registers a filter when starting, if I set presence to offline NMC
> > quits, if I set presence back to online NMC restarts and don't have the
> > registered filter anymore...
> 
> Ok, looks like we have to store the filters somewhere...
> 
> > I had an idea to merge concepts of chandler and filter together since
> > those 2 concepts are really close:
> > 
> > chandlers are registered by installing a .chandler file describing the
> > type of channel it wants to catch and the dbus service MC has to launch
> > to handle a new channel. We can permit more than one chandler file per
> > channel type, with a priority field. When MC gets a channel it takes the
> > most priority chandler and starts it, this chandler is responsible of
> > the new channel until it closes it (the channel is then removed from MC)
> > or tell MC to dispatch it to the next registered chandler in the
> > priority queue, if there is no more chandler MC close the channel.
> 
> Mmmm... but under what case would a chandler pass the channel to another 
> chandler?

For example, I register 3 chandlers for a Text Channel, in order of
priority:

1) Logger filter, it takes the channel and keep it to log everything in
a log file. A it tell the MC to give the channel to the next chandler.
2) StatusIcon, it blinks to warn the user there is a new conversation
and wait for the user to click on the icon, then it tells the MC to
start the next chandler.
3) The chat UI program takes the channel and displays the conversation.

So chandlers acts like NMC filters, no need of 2 concepts that are very
similar.

> > Like that filters are nothing else than a channel handler with an high
> > priority.
> > 
> > What do you think about?
> 
> We are planning to add a "Protocol" field to the chandler files, so that 
> different UIs might be started for different protocols. If we unify 
> channel handlers and filters at the same level, we might have to add a 
> "Protocol" field to the filters too; this doesn't make much sense, in 
> most of the cases.

We can just leave the protocol field empty (or omit it) which would mean
"I want to get channels from all protocols".

> Maybe we can have one low-priority filter for starting the channel 
> handler, but I don't see any benefit of this approach over the current 
> implementation.

I think the benefit is to have an easier implementation of MC, with my
proposal we just have to extent a little bit the concept of chandler to
remove completely the filter code (which is buggy in my implementation
in NMC anyway).

Xavier.