[Telepathy] Offline cache

[Travis Reitter]

On Fri, 2013-03-15 at 09:29 +0100, Xavier Claessens wrote:
> 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.

Agreed completely.

> 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?

I would be happy to move this functionality from Folks into its
backends' implementations. That seems to be the proper place for the
caches to exist, since they're generally necessary for those components
on their own anyhow.

EDS already has its own cache and we just need the vCard and avatar
caches for Telepathy you describe above before we could rely upon that
and drop the caching in Folks, I think.

I think the only caching Folks itself should need would be:

* link/aggregation cache (fdo#687671). This wouldn't be a concern for
  Telepathy itself, but I'm just listing it for completeness. Start-up
  aggregation for Folks is a lot of repeated work which is mostly
  redundant for almost all Folks client runs between Telepathy account
  adds/removes (so, ~all runs).

* (possibly) the core vCard (mainly alias/nickname/Full Name) + avatar
  for favorites in a format that can be displayed extremely quickly.
  This would be an optimization around worst-case performance risks of
  the full cache and I'd only implement if we can't guarantee good
  performance in the general case using the caches below us. Though
  depending on the implementation of the aggregation cache, this may
  just be a matter of adding a bit for whether each is a favorite and
  convenience API to retrieve just those Individuals (first).

Did I miss anything, Philip?

-Travis