[Telepathy] MissionControl's spec

[Xavier Claessens]

Le lundi 22 octobre 2007 à 11:50 +0300, Alberto Mardegan a écrit :
> 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?

I'm not sure about that, we need to have an Account object to call
GetParameters and know what needs to be filled by the user. NMC don't
show incomplete accounts, I'm not sure it's a good idea, that's a
problem I have in Empathy: The user creates an account, is close the
window before the account get completed, when he opens the dialog later
it the account disappeared.

I think AddAccount should return an empty account based on a profile,
the complete-ness should be done client-side.

We should have GetParameters () → a(susv) like in ConnectionManager
interface to let the client know if the param is required, Empathy needs
that for EmpathyAccountWidgetGeneric.

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

I want MC spec looks like TP spec. TP spec has separate iface/methods to
set alias/avatar/etc and it don't uses the parameters dictionary for
that, why should MC do?

You're right, MC spec miss a {Set|Get}Alias{Updated} and spec should
make clear that MC must call SetAlias and SetAvatar each time the
account gets connected.

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

True... I'm a bit lost here... Does someone has a clear idea of what
profiles should be?

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

Ok, we can define a {Set|Get}DefaultPresence{Updated} on AccountManager.

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

Ok, but it should return an error if default presence is offline.

> Ciao,
>    Alberto

Thanks,
Xavier.