[Telepathy] Offline cache

[Xavier Claessens]

Hello,

I've been thinking about the various on-disk caches we need for
telepathy.

Use cases
---------

1) Avatar cache: avoid re-downloading the image when protocol gives a
token.

-> Already well covered in TpAvatarsMixin and Avatars1 spec:
https://bugs.freedesktop.org/show_bug.cgi?id=55920

2) Avatar cache: offline XMPP contacts does not know their avatar token,
but we should still announce the last known avatar.

-> IMHO it makes no sense to write avatars on disk in multiple places,
so we should reuse the existing avatar cache. So gabble could store on
disk a contact-id -> avatar-cache-uri map. With the new spec that's
enough because we expose only the URI to clients.

3) Avatar cache: telepathy-logger wants to give the avatar that the
contact had at the time the archived message was received.

-> Again, IMHO, it makes no sense to duplicate the avatar cache, so
tp-logger could just write the URI in the logs.

4) Nickname cache: this could be specific to gabble, but we don't want
to re-download the full vcard just to tell contact's nickname. It is
enough to tell the last known nickname and requiring an explicit refresh
if client wants the latest.

-> This has been discussed a bit for TpNamesMixin:
https://bugs.freedesktop.org/show_bug.cgi?id=14540.

5) VCard cache: similar to nickname cache but for the full vcard. We
want to have last known ContactInfo without an explicit request.

6) Full offline cache: when using Folks we want the same information
inside an individual regardless of the onliness.

7) Incremental roster: with some protocols we can store the last known
roster, so we download only what changed when connecting. This is really
specific to each protocol.


Suggestions
-----------

- I think 1, 2 and 3 are all already pretty well covered, just need to
land TpAvatarsMixin work.

- 4 is a special case of 5, so we probably only need a vcard cache. This
needs to be done in CM and format can be implementation detail.

- 6 is currently done in folks, but I think it's wrong, because folks is
not a daemon, but a client lib. So currently it means that at least one
client must know everything about all contacts. If multiple clients do
that they will write into the same cache?

Simon suggested doing it in MC and add a GetContactAttributes method on
Account interface that works offline. I totally love the idea of a dbus
method on Account with same signature than what we already have on
Connection. However this means yet another process that must know
everything of all contacts. So I think the cache writing should be done
from CM process, but accessed from Account because that's what we have
when offline.

Maybe the cache is not a spec thing, but a tp-glib specific feature.
TpBaseConnection writes the cache on disk, and TpAccount reads it. When
going offline, TpBaseConnection constructs a GVariant as if
GetContactAttributes was called on all contacts for all features and use
GDBusMessage to serialize it (because then it's easy to read from tp-qt
as well). Then TpAccount can read that file to reconstruct the GVariant
and create TpOfflineContact objects, that would have same API than
TpContact but immutable. Also I think we need one file per contact, to
avoid parsing the huge GVariant when needing only one TpOfflineContact.

Another advantage of writing the cache from CM, is that it can be used
for the vcard cache as well.

- 7 is probably really specific to protocols, so I don't think that can
be shared with what I suggested above. So that would be stored
separately in protocol specific format.

Voilà, comments?

Regards,
Xavier Claessens.