[Telepathy] MissionControl's spec

[Xavier Claessens]

Le mardi 23 octobre 2007 à 14:55 +0300, Alberto Mardegan a écrit :
> ext Xavier Claessens wrote:
> > 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.
> 
> It would be even better if we made the creation of non-complete accounts 
> impossible at all. To know what parameters needs to be filled by the 
> user you don't need an account object; somewhere in the AccountManager 
> (or in a Profile class) there should already be a list of what 
> parameters need to be filled in.

I'm not strongly against making impossible to create incomplete
accounts, but what if the user has a working complex SIP settings and
removes one required param? The account gets removed and all other
params are lost?

What's bad with having non-complete accounts? MC can just ignore them
when connecting... And RequestChannel can return "error: incomplete" for
example. If we give param flags in GetParameters() client can calculate
itself if an account is incomplete and do whatever it wants with it. I
think it's a more natural way.

> [...]
> > 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.
> 
> I wouldn't make it in the Account interface. I'd think of 
> GetParameters() as a DBus version what we currently have in NMC, that is 
> a method that lists all the parameters that are going to be passed to 
> the connection manager (if needed, we can add an enum that tells where 
> the value comes from: account, profile, some provisioning service...).

If we decide to reject incomplete accounts, GetParameters() should be
moved to AccountManager, otherwise it makes sense in Account, IMHO.

I agree we should add an enum to tell were the value comes from.

> > 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?
> 
> I was thinking of FindAccounts(): maybe you need to find an account by 
> display name. But I agree that putting these settings in the same 
> dictionary is a bad idea, so we can probably live without it and just 
> let those who are interested to call FindAccounts() with an empty filter 
> and call GetDisplayName() on all the results to check if that is the 
> account we wanted -- but it might be kinda slow.

You have special keys described in the spec, you can do
  FindAccounts(["display_name", "my account"])

> > 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.
> 
> Why? You don't want to override the ones stored in the server, if you 
> didn't change yours locally.

NMC does that. Some protocols (MSN) don't store alias/avatar on server
so we have to set it each time we connect. Maybe profiles should have in
the capabilities field something like "can-store-avatar-on-server" to
let MC know if it should call SetAvatar when the account gets connected.

> >>> 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.
> 
> I'm not sure about this; in the N800 we set the presence to invisible in 
> that case, because we assume that if the user wants to call someone, he 
> knows that a connection to the internet will be established.

Hum, invisible is not supported by Jabber IIRC, and N800 only supports
Jabber... 

An example for why I think returning an error if the account is not
connected:
The user is viewing emails in evolution, MC/Empathy is not running
because the user uses pidgin so accounts are offline. The user clicks on
"reply by IM" button in evolution (when evo will support such thing) and
evolution calls RequestChannel to start a conversation. MC connects the
account to "available" (if that's the default presence) and the chat
begins... The user closes the window, the Text Channel is Closed, the
account stay connected and the user has no way to know he is still
connected, he can't disconnect the account, and all his contacts think
he is available.

If we return an error in RequestChannel evolution has 2 choices:
1) Call ConnectAll() or SetPresence(available) and call RequestChannel
once it's connected. In that case evolution knows he is responsible of
that connection and should display some UI to disconnect or something...
2) Display an error asking the user to start Empathy, with a button
"click here to start empathy".

> Ciao,
>    Alberto
> 

I have one more point: Current spec don't have a "enable" property on
accounts, what was the reason for that? Did we agreed that Group system
can be used by clients to have a "enable" and "disable" groups? Or
should I add {Get|Set}Enable{Changed} on Account interface?

Xavier.