[Telepathy] MissionControl's spec

[Alberto Mardegan]

ext Xavier Claessens wrote:
> I opened a darcs branch to add MissionControl's spec into
> telepathy-spec[1].

Some remarks, in random order:

- wasn't it agreed that AddAccount would take an array of all the
parameters, so that the creation of an _usable_ (or "complete" in NMC 
sense) account be atomic?

- Are avatar and display name to be manipulated by different APIs, or 
treated as parameters? In the latter case, we should probably add two 
arguments to the AddAccount function: one for connection parameters, and 
one for MC settings (or they could be in the same dictionary, with a 
different namespace); in case we want to keep them split, we can add a 
{Set|Get}Settings() API, but we need also to consider reviewing 
FindAccounts().

- Alias needs to be handled in the same way; either with a separate API, 
or within the parameters/settings dictionary

[...]
> 1) org.freedesktop.Telepathy.MissionControl.ProtocolManager: Is that
> interface useful at all? libtelepathy already has code to do such
> things. I think we should think about a good profile system instead.
> Information in NMC profiles:
[...]
> So who should install profiles? If each client install his set of
> profiles and the user install kopette and Empathy, he will have 2
> profiles for gabble... If the CM install profile how could we have
> translated fields, icons, etc? I don't know how to do that right.

Another problem is that some services might want to install their own 
profiles; think of SIP, there are a lot of providers, and it would make 
sense to have a different profile for each of them, each with its 
default settings/parameters.
IMHO we definitely need a separation between UI settings and CM/service 
settings, so that installing a new UI would make it immediately usable 
with all services already installed, and adding a new service file will 
allow every UI to make use of it.
But I still don't know how to match this with the API...

[...]
> 4) ConnectAll: is that useful? The default presence is not defined in
> the spec... I think it can be easily replaced by SetGlobalPresence. Or
> maybe we should define in the spec that MC must save presence for all
> accounts and calling ConnectAll will restore saved presence? In that
> case ConnectAll could be renamed to ResorePresence?

I think that the default presence can be the same for all account, so I 
would rather add an API like SetDefaultPresence to the AccountManager 
interface, and let ConnectAll request it. Automatically saving the 
presence seems a bit complex.
We could also have a SetDefaultPresence method in the Account objects, 
too, if we really want to be able to specify a different default 
presence for each account.

> 5) RequestChannel: description says "putting the account online if
> necessary". Ok but with which presence? I think that method should just
> return an error NOT_CONNECTED in that case.

We should connect with the default presence, as defined in the previous 
point.

Ciao,
   Alberto


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