Opened bug #33410 for contact avatar

Complexity: MC currently uses the same filename every time. To indicate *changes* in a useful way, I think we'd have to do something similar to contacts' avatars: have something in the signal that's guaranteed to change every time. It can either be a unique URI per change, or a separate change-indicator. We can't use the avatar token, because if you set your avatar while online, MC doesn't know what token is going to be used; it'd have to be a sequence number or something.

We could do something like this:

    Account.AvatarURI: s, read-only
        A file:/// URI pointing to the account's avatar.

        | We use a file:/// URI rather than a filename because
        | Unix paths are not guaranteed to be UTF-8, or any consistent
        | encoding at all.

        The URI must change every time the bytes of the avatar are changed
        (for instance, an implementation may copy avatar data into a
        file whose name includes a sequence number). Other than that, its
        structure and location are implementation-defined.

        Change notification is via AccountPropertyChanged.

    Account.AvatarMIMEType: s, read-only
        The MIME type of the file at AvatarURI. This property
        SHOULD appear in the same AccountPropertyChanged signal
        as Account.AvatarURI.

        Change notification is via AccountPropertyChanged.

    Account.SetAvatar(ay: Bytes, s: MIME_Type)
        If the account is currently connected and supports avatars,
        attempt to change its avatar immediately.
        If not, remember that the change has occurred, and
        attempt to make the change next time the account becomes
        connected.

and have the URIs be something like file://${XDG_DATA_HOME}/telepathy/mission-control/salut-local_xmpp-account0.${SEQ}.avatar, where ${XDG_DATA_HOME} is what you'd expect, and ${SEQ} is a 32-bit counter (with wraparound if you change it far too often)? We'd store the sequence number in the account data as a pseudo-property, and construct the URI at .

We can't just put it in the avatar cache, because on protocols like Salut where avatars are transient, this is really configuration.

Open questions:

* should SetAvatar wait for Conn.I.Avatars.SetAvatar, if connected,
  before returning?
* if Conn.I.Avatars.SetAvatar fails, should we still update AvatarURI and
  AvatarMIMEType, so we'll have another try next time we connect?
  Or should we change them when we start the attempt, and change them
  *back* if it fails?

(In reply to comment #0)
> Since AM is supposed to save on disk the avatar, it is convenient for
> clients to get it as URI. For example contactsd (meego telepathy->tracker
> daemon) need to save again on disk which could be avoided if AM communicate
> where it already saved it.

What do loggers, Tracker/Zeitgeist/etc. interfaces, etc. want to save? Do they want "the avatar of this account", or do they want "the avatar that this account had at the time"? If they want the latter, then they'll still need to copy it (perhaps with something clever like a a hard-link) - unless either we make MC guarantee to keep all the old avatars, which seems pretty crap, or the logger etc. is prepared to cope with old avatars disappearing over time (e.g. when a cache is cleaned).

One possible refinement would be to have an "AvatarID" that is guaranteed to be long-term unique across all accounts, and in a restricted character set, in addition to the AvatarURI (implementation detail: the AvatarURI would be file://${XDG_DATA_HOME}/telepathy/mission-control/${AVATAR_ID}). Or, guarantee that the part of the URI after the last "/" is long-term-unique and in a restricted character set. Then loggers, etc. could copy or link the avatar to some location under their control, perhaps ${XDG_DATA_HOME}/telepathy/logger/old-avatars/${AVATAR_ID}, if they want to hang onto them?

Possible implementation: the avatar ID is "sha1-" + SHA1(contents) + ".avatar".

tp-logger stores only the avatar token of the TpContact (even for self contact), and empathy knows how to reconstruct the file URI in the cache from that.

I think tp-logger should instead just store the full URI.

For account avatar, I think MC should keep the URI of the self contact avatar when the account is online. If user set an avatar when account is offline it could store temporally the avatar somewhere with a unique path that change for each image. That could coincidentely be the sha1 of the image and match what the self contact will later have when account goes online...

(In reply to comment #4)
> I think tp-logger should instead just store the full URI.

Hmm, what happens when you move your $XDG_CACHE_HOME (or $HOME)? "You lose", I suspect... perhaps the new avatars spec should be using relative URIs, defined to be relative to $XDG_CACHE_HOME or $XDG_CACHE_HOME/telepathy/avatars or something?

(They'll also be pretty repetitive, which isn't great for log size.)

> If user set an avatar when account is
> offline it could store temporally the avatar somewhere with a unique path
> that change for each image.

On protocols that don't store the avatar on the server (mainly local-xmpp at the moment), this can't be temporary - it has to persist long-term (it's configuration, not cache).

(In reply to comment #5)
> (In reply to comment #4)
> > I think tp-logger should instead just store the full URI.
> 
> Hmm, what happens when you move your $XDG_CACHE_HOME (or $HOME)? "You lose",
> I suspect... perhaps the new avatars spec should be using relative URIs,
> defined to be relative to $XDG_CACHE_HOME or
> $XDG_CACHE_HOME/telepathy/avatars or something?
> 
> (They'll also be pretty repetitive, which isn't great for log size.)

Hmm, indeed the prefix can be defined in the spec and we could transmit only the suffix.

> > If user set an avatar when account is
> > offline it could store temporally the avatar somewhere with a unique path
> > that change for each image.
> 
> On protocols that don't store the avatar on the server (mainly local-xmpp at
> the moment), this can't be temporary - it has to persist long-term (it's
> configuration, not cache).

ah right.

*** Bug 54916 has been marked as a duplicate of this bug. ***

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/105.