[Telepathy] Proposed standard MC API

[Alberto Mardegan]

ext George Wright wrote:
>> Is Decibel using components only for handling channels as Nokia MC does,
>> or do they something more?
> 
> I believe they only handle channels. Decibel's components currently only 
> expose a channel handling API, but you'll have to talk to Tobias Hunger about 
> that.

Nokia MC has also channel filters that can be installed as DBus 
components; it's something badly needed especially for handling incoming 
channels, so we should standardise that too.

> That sounds sensible. How would the profiles be referenced by the client? MC 
> should deal with the locating and indexing of which profiles are available, 
> not the client, in my opinion. Maybe string or integer handles assigned by MC 
> which can be obtained through a ListProfiles ( ) -> a(so) linking profile 
> handle to connection manager object path?

We need something more: a profile is an object having a display name, an 
icon, and a set of default protocol parameters. I think it's worth to 
create a DBus object for them, too.
The account configuration clients will need to retrieve the list of 
available profiles (MC will take care of finding them in the filesystem 
and will provide a ListProfiles API), and present them (as a name and 
icon) to the user when he'll want to create a new account. Then, they 
will be used internally by MC to provide default values for the 
parameters that are unset in the account.

IMHO, profiles (and protocols, and managers) should be considered 
read-only objects from a client point of view.

> Also, that seems to have the effect of not being able to create an account 
> without a profile. Are there any use cases for wanting to be able to create 
> an account with no profile set?

At least the account must hold the information about what protocol it is 
using; in Nokia MC this information is stored in each profile. We could 
live without profiles if we store this information somewhere else, but 
then we would still need to figure out where to put the icon and a 
display name for the service (which are desirable things).

>> 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().
> 
> If we were to do that I think AddAccount and CreateAccount are a bit too 
> similar. Perhaps if we were to rename AddAccount to ActivateAccount, that 
> would make more sense.

Are you talking about naming only? It's OK for me, even if I don't see 
anything bad with create/add either (create() creates an unbound 
account, add() adds it to the AccountManager).

> Alternatively, we could create accounts disabled by default and then when they 
> are enabled a signal is emitted such as AccountEnabled ( o: account ), and 
> AccountCreated is still emitted when an account is created, but it is 
> disabled by default.

No, in the N800 UI as soon as an account is created (with all its 
settings complete) it is shown in the UI, be it enabled or not. 
Enabledness only comes into play when we have to decide whether to put 
the account online or not; but for showing and editing, we need a signal 
that tells us when the account is ready to be presented to the user.

>> 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.
> 
> Is it better to expose this over the D-Bus API instead of making clients parse 
> the .manager files?

Yes; I presume most clients won't care too much about the protocol 
parameters, but still one could design a (poor) universal account 
configuration UI that dynamically creates the widgets for every protocol 
parameter.

>> Also, some way to link the bits together, that is from Account get the
>> Profile, and from the Profile the Protocol.
> 
> I think it might be best to add a ProfileManager interface which can deal with 
> the creation and deletion of profiles. Modifying profiles may not be such a 
> good idea as it could end in disaster for those accounts relying on that 
> profile.

Mmm, as I said, I think of profiles as a read-only object. They are just 
installed and uninstalled as packages.

>> 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).
> 
> The problem we have with the CM providing them is that if they provide the 
> profile and there is more than one CM installed for a specific protocol, then 
> there may be conflicts within MC as to which CM should be chosen.

Good point. But would this be per profile or per account? I'd let it be 
per account, and have an account settings decide it; or MC will pick up 
the first connection manager that can handle the protocol.

Ciao,
   Alberto

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