[Telepathy] Proposed standard MC API

[Alberto Mardegan]

Hello,

ext George Wright wrote:
[...]
> The idea of this project is to allow clients to be written to
> a standard API and not have them tied down to any one single
> implementation of Mission Control.

Nice, this was really needed.

> So far I have made the following decisions:
[...]

All of those seem fine to me.

> SetPresence ( u: presence ) -> nothing

Since Telepathy API allows setting and retrieving presence+message with
a single call, I think we'd better do the same in mission-control.

> SetEnabled ( b: enabled ) -> nothing
[...]
> IsEnabled ( ) -> b

Small remark about naming: [Get|Set]Enabled, or [Enable|IsEnabled] seem
more consistent.

> - Abstract plugins like Decibel's "Component" system. These are like
>   Nokia Mission Control's channel handlers and filters. We need to come
>   up with a standard API for these. 

Is Decibel using components only for handling channels as Nokia MC does,
or do they something more?

> - Accounts; enabled, normalised name, display name, etc - do we want to
>   implement these as D-Bus properties or methods?

I'll leave the decision to someone more expert about D-Bus. :-)

> - We need something like Nokia Mission Control's "Profiles" system 
>   because changing a connection manager for a given protocol isn't
>   necessarily going to work as there is no exhaustive standard
>   for the configuration settings a given connection manager should
>   take. Particularly, we need to decide on who provides the profiles; 
>   Mission Control, the UI or somewhere else?

This has also some impact on the accounts API: AddAccount (which I would
rather call CreateAccount) needs to receive the profile in input. About
account creation, Nokia MC does not emit the "AccountCreated" signal
until the account is complete (i.e., all the required parameters are
set), because it's likely that clients listening to this signal would
respond to it trying to get some information on the newly created
account, or put it online.
Maybe we could split the API into two different parts:

CreateAccount ( [s:profile?] ) -> o

That creates the account object but doesn't return it in ListAccounts
and friends, and maybe emits an AccountCreated signal (but would it be
of any use?), and

AddAccount ( o:account ) -> nothing

that will register the account to the AccountManager and emits the
AccountAdded signal.
So, for creating an account one would call CreateAccount(), set all the
needed properties/parameters, and then call AddAccount().

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.

Also, some way to link the bits together, that is from Account get the
Profile, and from the Profile the Protocol.

About your last question, on who should provide the profiles, I wouldn't
be so concerned about that: they could be provided by the connection
manager, if it is so specific that the profile can be shipped together
with it (for instance, ICQ, Yahoo and MSN won't probably need more than
one profile), or by some third party (every SIP service would probably
want to provide a profile).

Ciao,
   Alberto


-- 
http://www.mardy.it <-- Geek in un lingua international!