Mail forwarded, I forgot to CC tp ML.<br><br>---------- Forwarded message ----------<br><span class="gmail_quote">From: <b class="gmail_sendername">Xavier Claessens</b> &lt;<a href="mailto:xclaesse@gmail.com">xclaesse@gmail.com
</a>&gt;<br>Date: 15 mai 2007 19:54<br>Subject: Re: [Telepathy] Standardising Mission Control<br>To: Alp Toker &lt;<a href="mailto:alp.toker@collabora.co.uk">alp.toker@collabora.co.uk</a>&gt;<br><br></span>On another topic, something that should be part of the spec as discussed on IRC with naba:
<br><br>Actually nokia&#39;s MC has a plugin system to register filters. Basically a plugin register itself and tells the MC if a channel should be dispatched or not. Filters can be provided by the UI (the status icon). For example I want to make a status icon that blinks when I receive a new message from one of my contacts with a libnotify bubble displaying the first message received and only start the chat program when the user click on then icon. Actually with nokia&#39;s MC I have to register a filter plugin (linked into MC itself) which will do DBus calls to tell the status icon for new channels to be filtered... If think that work should be done in the core of MC. Here is a quick proposal for a DBus API:
<br><br>On Mission Control&#39;s API:<br>method RegisterFilter (bus_name, object_path, channel_type)<br>--&gt; Where bus_name and object_path discribe the object registered on the bus providing a the filter interface<br>
<br>
The filter interface should have:<br>method FilterChannel (Channel, Connection)<br>--&gt; called by MC on the object given in by RegisterFilter to tell the filter program that there is a new channel to be filtered<br>signal FilterChannelProcesse(Channel, connection, bool dispatch)
<br>--&gt; emitted by the filter program to tell the MC that channel should/shouldn&#39;t be dispatched<br><br>Is there comments on that ?<br><br>Who is working on writing a draft spec ? I think we can start to write it.
<br>
<br>Xavier Claessens.<br><br><div><span class="gmail_quote">2007/5/9, Alp Toker &lt;<a href="mailto:alp.toker@collabora.co.uk" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">alp.toker@collabora.co.uk
</a>&gt;:</span><div><span class="e" id="q_11290e076dedbb9d_1"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We have the situation right now where Decibel and Mission Control do<br>many similar things in different ways.<br><br>I wanted to get discussion going on how we might start to standardise<br>the D-Bus APIs and formats used internally by these implementations to
<br>allow for greater interoperability.<br><br>Some possible desirables:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;* Client/service separation: Allow for lightweight client<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;implementations by doing as much work as possible in the service.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This would mean having D-Bus API not only for for accessing
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;accounts but also for manipulating account details.<br>&nbsp;&nbsp;&nbsp;&nbsp;* Standardise the account store format to ease migration between<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;desktop environments and possibly even mobile devices.<br>&nbsp;&nbsp;&nbsp;&nbsp;* Avoid monolithic interfaces in favour of smaller ones that deal
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with individual roles eg. account management,&nbsp;&nbsp;unified contacts,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unified presence. Implementations with specific needs can then<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;concentrate on the features they need to support.<br><br><br>My preliminary investigations have shown that Decibel is closer to these
<br>goals, while there is more code behind mission-control and it has been<br>deployed widely, albeit on embedded devices. Both code bases are large<br>enough that standardisation will not be trivial.<br><br>I&#39;d like to hear what the authors of these components and their users
<br>see as a possible future direction that brings these frameworks together<br>and lays groundwork for future implementations.<br><br>_______________________________________________<br>Telepathy mailing list<br><a href="mailto:Telepathy@lists.freedesktop.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

Telepathy@lists.freedesktop.org</a><br><a href="http://lists.freedesktop.org/mailman/listinfo/telepathy" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.freedesktop.org/mailman/listinfo/telepathy
</a><br></blockquote></span></div></div><br>