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. _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy