[Telepathy] Account and AccountManager objects

[Simon McVittie]

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

On Wed, 30 Jan 2008 at 14:39:13 +0200, Alberto Mardegan wrote:
> ext Simon McVittie wrote:
> > OK, here's an API sketch.

> BTW, I always forgot to 
> mention that connectivity information provided by connectivity plugins 
> could also affect the account parameters: for instance, the SIP CM 
> accepts a "local-ip-address" parameter. We could make it so that if the 
> connectivity parameter's name matches a protocol parameter, then it's 
> passed to the CM. Slightly hackish, but cannot think of anything better ATM.

It's unclear to me what the requirements are here. Is the goal that we
tunnel all the SIP RTP streams through whatever VPN is available, or what?
This is somewhat reminiscent of the special cases MC currently has for
setting up HTTP/HTTPS proxies using configuration from gconf.

With this sort of thing in mind, we definitely want conditions and so on to
be an add-on interface! We can replicate the functionality of the current MC
without them, so if necessary we can put them to one side, define the
core interface somewhat vaguely ("do foo if possible"), and come back
to them.

> > org.freedesktop.Telepathy.AccountManager.Preset
> Anyway, if we want to expose the presets on DBus, we also need a method 
> to list them.

Yeah, obviously.

> > Should MC support arbitrary (namespaced) key/value attributes, which it
> > doesn't understand but can just pass through?
> 
> Yes. Sticking to .desktop-style files, I'd allow them to have arbitrary 
> [sections].

I think we should make an obvious distinction between things that are
expected to change MC's behaviour, and things that are "just client stuff".
This is particularly important if profiles/presets are on D-Bus. Perhaps
we should stick to files for the moment, and move to D-Bus if there's a
need for centralized inotify'ing.

> > Locale: s
> >   lang[_COUNTRY][.ENCODING][@MODIFIER], or ""/"C"/"POSIX" (all equivalent)
> 
> I don't understand the meaning of the "Locale" type.

It's a locale (loosely: language environment) into which apps can be
localized. For instance en (English), en_US (USA English), pt_BR.UTF-8
(Brazilian Portugese with UTF-8 encoding).

This is a straightforward mapping of .desktop localization into the
D-Bus interface. Locales like this are also the "languages" that
gettext() will choose between, if you choose to use it.

> > org.freedesktop.Telepathy.Account
> > =================================
> [...]
> > DesiredStatus: (uss), read/write
> >   A struct (Connection_Presence_Type, CM-specific presence status, message)
> >   indicating what status we'll want if we put this account online.
> >   As a special case, hidden indicates "hidden if possible, else busy",
> >   while offline indicates "hidden if possible, else offline".
> 
> Mmm... what is Connection_Presence_type?

It's the enumerated type from the Telepathy spec that contains Unset, Offline,
Available, Busy, Away etc. See:
http://telepathy.freedesktop.org/spec.html#type-Connection_Presence_Type

> BTW, I see that you moved most of the data into properties. Seems fine 
> to me, but I have never used them and I'd like to be assured that they 
> also emit signals when their value changes, and that these signals carry 
> the new value (I couldn't find any mention to property signals in the 
> DBus specs).

The D-Bus core Properties interface doesn't include any change notification,
but that's why I put property change notification on the TODO list. I'd
probably add a signal per interface like this:

AccountPropertiesChanged (a{sv}: New_Values)
  Properties from the Account interface may have changed. New_Values
  is a map from property names to values; it contains at least the
  properties that have changed, and MAY contain unchanged properties.

D-Bus core Properties are namespaced by interface names; the Properties
interface is very simple, containing three methods (Get and Set, which do
what you expect, and GetAll, which gets all the properties of a
specified interface). So the calling sequence would be:

connect to o.fd.Telepathy.Account.AccountPropertiesChanged
call o.fd.DBus.Properties.GetAll("o.fd.Telepathy.Account")
connect to o.fd.Telepathy.Account.Interface.Extra.ExtraPropertiesChanged
call o.fd.DBus.Properties.GetAll("o.fd.Telepathy.Account.Interface.Extra")
... and so on ...

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

iD8DBQFHoHb1WSc8zVUw7HYRAlVeAKCuyZL6p2W1J0ayb2qPTnmZ8wbawwCgyz3d
I5SJfEiGLWAdrrkGrrcm9K0=
=9mi8
-----END PGP SIGNATURE-----