[Telepathy] Fwd: Standardising Mission Control

[Xavier Claessens]

Mail forwarded, I forgot to CC tp ML.

---------- Forwarded message ----------
From: Xavier Claessens <xclaesse at gmail.com>
Date: 15 mai 2007 19:54
Subject: Re: [Telepathy] Standardising Mission Control
To: Alp Toker <alp.toker at collabora.co.uk>

On another topic, something that should be part of the spec as discussed on
IRC with naba:

Actually nokia'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'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:

On Mission Control's API:
method RegisterFilter (bus_name, object_path, channel_type)
--> Where bus_name and object_path discribe the object registered on the bus
providing a the filter interface

The filter interface should have:
method FilterChannel (Channel, Connection)
--> called by MC on the object given in by RegisterFilter to tell the filter
program that there is a new channel to be filtered
signal FilterChannelProcesse(Channel, connection, bool dispatch)
--> emitted by the filter program to tell the MC that channel
should/shouldn't be dispatched

Is there comments on that ?

Who is working on writing a draft spec ? I think we can start to write it.

Xavier Claessens.

2007/5/9, Alp Toker <alp.toker at collabora.co.uk>:
>
> We have the situation right now where Decibel and Mission Control do
> many similar things in different ways.
>
> I wanted to get discussion going on how we might start to standardise
> the D-Bus APIs and formats used internally by these implementations to
> allow for greater interoperability.
>
> Some possible desirables:
>
>     * Client/service separation: Allow for lightweight client
>       implementations by doing as much work as possible in the service.
>       This would mean having D-Bus API not only for for accessing
>       accounts but also for manipulating account details.
>     * Standardise the account store format to ease migration between
>       desktop environments and possibly even mobile devices.
>     * Avoid monolithic interfaces in favour of smaller ones that deal
>       with individual roles eg. account management,  unified contacts,
>       unified presence. Implementations with specific needs can then
>       concentrate on the features they need to support.
>
>
> My preliminary investigations have shown that Decibel is closer to these
> goals, while there is more code behind mission-control and it has been
> deployed widely, albeit on embedded devices. Both code bases are large
> enough that standardisation will not be trivial.
>
> I'd like to hear what the authors of these components and their users
> see as a possible future direction that brings these frameworks together
> and lays groundwork for future implementations.
>
> _______________________________________________
> Telepathy mailing list
> Telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/telepathy/attachments/20070516/9335c022/attachment.htm