[Telepathy] Proposed standard MC API

[Robert McQueen]

Tobias Hunger wrote:
> On Thursday 02 August 2007, Alberto Mardegan wrote:
>>> So far I have made the following decisions:
> 
> I don't like you getting inspiration from Decibel and then claim all the 
> credit by calling it org.freedesktop.Telepathy.MissionControl does not sound 
> fair to me.

What we are trying to do here is address a gap in the coverage of the
Telepathy specification which has existed since the beginning. On the
very first scraps of paper on which we started designing Telepathy just
over two years ago at Debconf in Helsinki (see attached), we were
talking about what MC would need to do for the clients to make Telepathy
usable. In order for Telepathy to be a useful standard for client
authors, how to address an MC implementation needs to be part of the API
that we define.

To *not* address this within the Telepathy specification would seem to
me like libc not having malloc(), and to refuse to include it because
you have (and thank you so much!) helped us along the way would be like
HTML not including <img> because someone at Mosaic wrote an
implementation of it.

We've taken a lot of inspiration from Nokia's mission control as well as
Decibel, and the reasons are many. We don't want to come up with
something which is totally different to what either implementation does,
because that would make it harder for either party to adopt the
standard. We want to make sure that the resulting API addresses the use
cases that are relevant to the participants, so that there are no
barriers to adoption of the standard.

The credit is an issue I'm more than happy to address seperately with
appropriate acknowledgements in the headers, documentation, website,
etc, but the standard itself must be a part (and like the CM spec, the
specs are most important part of what we do) of the Telepathy project
and a product of the Telepathy community, including you, which is why
we're having the discussion on this mailing list.

> And the FirstUpperCase nameing convention is pretty much against everything 
> used in KDE.

Yes, and it's also not what's used in GNOME, POSIX, C++, Perl, Python,
Haskell, ML or Ruby. However, Telepathy and this mission control spec is
a D-Bus API, and it *is* what's used in D-Bus, and the rest of
Telepathy. It can (and is) mapped to local naming conventions by either
your D-Bus bindings, or a specifically written/generated client library.
dbus-glib/libtelepathy turns things into tp_foo_bar, or TP_FOO_BAR
depending on what you need, and I'm sure that QtDbus, Tapioca or the
Decibel library can do the same for KDE.

>> Is Decibel using components only for handling channels as Nokia MC does,
>> or do they something more?
> 
> They handle and filter channels.

NMC originally had in-process filter plugins, and Xavier later added the
ability for filters to register over D-Bus. The thing this lets you do
that seems harder with the component-returns-boolean idea is having a
seperate process queue/delay the channel handling (blink a tray icon or
whatever) than the one which finally handles the channel.

Whilst I appreciate the elegance of having filters and handlers under
one roof with boolean return values, can we use it in all of the same
cases that seperate filters can handle? I'm not sure, because even if
you arrange your handlers in a certain order so that your "blink the
tray icon" handler comes first? Wouldn't that method call time out?

> In decibel AddAccount takes a array of string/variant pairs. These must 
> contain a special decibel_protocol pair which lists the protocol the account 
> is meant to be used with.

As discussed elsewhere, I think we all agree the creation needs to be
atomic, so the profile and the params need to be passed in at creation
time. However, I think that it's a bad idea to mix the other things into
the same dictionary however, because the namespace for that dictionary
is defined by the Telepathy CM spec, and all MC does with it is store
and regurgitate it at the appropriate times.

> Decibel just errors out when somebody tries to create an account without 
> giving all the required parameters.

+1 for atomic failure on creating invalid new accounts. Best not even
have the option. Nokia MC has a confusing function (which I added, and I
regret :D) which tells you whether an account is "complete" or not, and
its really confusing.

>> In the ProtocolManager (or, probably better, in a separate Protocol
>> class) we need a method for retrieving the list of the valid protocol
>> parameters, with their type, default value and whether they are required.
> 
> Yeap. In Decibel the ProtocolManager can provide this kind of information.

>> Also, some way to link the bits together, that is from Account get the
>> Profile, and from the Profile the Protocol.
> 
> Decibel only exposes what you call a Profile. I see no reason to make the 
> mapping from profile to protocol public.

Yeah, I wouldn't go as far as exposing CM-level protocol and manager
objects in the MC API. In NMC, the only people who use this API is the
implementation of MC itself. Clients are only interested in profiles and
accounts. The information about the default values and their
requiredness, etc, should be represented via the profiles.

> Best Regards,
> Tobias

Regards,
Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02082007.jpg
Type: image/jpeg
Size: 299059 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20070802/c1ed94d2/attachment-0002.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02082007(001).jpg
Type: image/jpeg
Size: 306046 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20070802/c1ed94d2/attachment-0003.jpg