[Telepathy] Account and AccountManager objects

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 08 Feb 2008 at 09:59:48 +0200, Alberto Mardegan wrote:
> - About RequestPresence: "If we expect clients to care about changes to 
> the requested presence...". YES WE DO! :-)

OK, I'll make RequestedPresence a separate r/w property. I honestly
don't see the use-case though - could you explain what critical thing
I'm missing?

> - Groups/tags: as they were in Zdra's proposal, the API was quite simple 
> that IMHO it doesn't require a separate interface. I would just add them 
> to the basic Account interface.

These are sufficiently contentious that we want them in a seperate
interface, so we can jettison them and replace with something different
if it turns out we did them wrong.

The core interface is the one we can't get rid of (easily, anyway), so
it should be relatively minimal.

> - Also, SetPresenceOnGroup might be useful.

... obviously, the group interface must have this.

> - The FindAccounts API as it was in Zdra's proposal is extremely useful 
> for clients, I would add it now.

I'll look at the proposed API and see what I think. Possibly an extra
interface again, if I'm not convinced we'll want to keep it forever.

> - About the account parameters: "To get the complete arguments to 
> RequestConnection, clients must also look at the PresetParameters 
> property." and "Clients can obtain the mapping that would be passed to 
> RequestConnection by taking a copy of the PresetParameters property, 
> then merging in the values from the Parameters property, overwriting 
> existing values if necessary." are both going to be wrong. We already 
> have in NMC the possibility to compile in some "provisioning plugins" to 
> provide the account parameters on the fly; so, for this new API, at some 
> time we will want to specify an API for "parameter plugins" to provide 
> the account parameters (all of them, of just a few to be merged); these 
> could be the password (for a GUI plugin), some connectivity parameters 
> (IP address or other networking hints) or just any parameter.

PresetParameters is not "the parameters from a .preset", it's "all the
parameters that are pre-set". The AM API doesn't care where they came
from, only that they exist and have whatever values.

The only point of exposing these at all is to let account-editing UIs display
them as defaults, instead of falsely claiming that the values from the
.manager file/the CM will be used.

I'm not sure how this provisioning stuff could sensibly interact with
account-editing UI - do you have any thoughts on this?

> - As I read the IRC logs, Robert was proposing to have a separate 
> interface for that part of the API that makes sense only for the valid 
> accounts; I don't have an opinion about that, but I have an opinion that 
> RequestPresence and RequestChannel (together with all the relevant 
> properties and signals) should be together in a same interface.

Rob and I don't think RequestChannel should be in the AM. It's conceptually
closer to handling incoming channels, in the (as yet unwritten) channel
dispatcher API.

> BTW, I didn't find any documentation about DBus object properties, other 
> than a mention to a exported_properties field in the DBusGObjectInfo 
> structure. How do they work? Does dbus-glib automatically exposes those 
> GObject properties that are listed in the exported_properties field?

dbus-glib implements them badly (see recent discussion on the D-Bus
mailing list, and conversation starting with me going "epic, epic failure"
on #telepathy). I'm going to have to do some hacking on either telepathy-glib
or dbus-glib before we can usefully use them.

For now, rather than implementing new APIs, would you mind concentrating on
porting MC (at least client API) to use telepathy-glib TpChannel etc., with
libtelepathy TpChan etc. only appearing for backwards compatibility? Please
send me any patches you want reviewed.

    Simon
-----BEGIN PGP SIGNATURE-----

iD8DBQFHrFvfWSc8zVUw7HYRAltfAJ47f5r9S6CAQ1zF0PBAeZpguHVx/QCdEDec
CJdO31RtTIs7XQbWWZr2iXk=
=hpaB
-----END PGP SIGNATURE-----