[Telepathy] Proposed standard MC API

[George Wright]

On Thursday 02 August 2007 12:15:28 Alberto Mardegan wrote:
> Since Telepathy API allows setting and retrieving presence+message with
> a single call, I think we'd better do the same in mission-control.

That would probably be sensible.

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

Seems reasonable. I think [Get|Set]Enabled is probably better in this case as 
an Enable function would also be able to disable it.

> 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.

> 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 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?

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?

> 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.

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.

> 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?

> 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.

> 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.

Regards,

George
-- 
George Wright, http://www.gwright.org.uk
Collabora Ltd - http://www.collabora.co.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20070802/51e9de7e/attachment.pgp