[Bug 62378] Offline contact caching

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62378

--- Comment #4 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #2)
> I'll add the self contact's id into the path then. It can be retrieved using
> tp_account_get_normalized_name() from client-side and TpBaseConnection can
> of course easily inspect self handle. AFAIK that's enough to make it
> unambiguous, right?

It is for XMPP, unless people are doing particularly stupid things with
non-federated XMPP servers.

It's ambiguous for IRC, though: idle/irc/alice/bob is not enough to know which
chatnet Alice and Bob are on (and Bob on OFTC is not necessarily the same
person as Bob on Freenode).

What is the intended scope of this cache? Protocols with persistent server-side
contact lists?

One way to defeat this ambiguity would be to include the Account object path
"tail" as a (special, reserved, built-in to MC) CM parameter, use that as part
of the directory, and disable this interface if that information is not
supplied.

Alternatively, a potential counter-proposal would be to say something like
this:

Telepathy is an abstraction for IM servers/networks/protocols. Anything not
present in the protocol, including faking a contact list for protocols that
don't maintain one, should not be part of Telepathy, but part of something
higher-level like Folks (which can also do contact linking and other useful
stuff, so you probably want it anyway).

(In reply to comment #1)
> 3) Data is serialized into the file using g_variant_get_data(). Is that
> format documented? Does Qt world have a parser for that? Would be preferable
> if tp-qt can use the same disk cache.

GVariant is not a standardized or documented format. The documentation is the
implementation. Also, a "bare" GVariant is native-endian for the architecture
on which it was written, and will import differently on x86 vs. PowerPC:
mis-importing is not detectable unless you deliberately include an endianness
flag.

Using the D-Bus message encoding (GDBusMessage) would be one way to make it
portable and endian-neutral, but to be honest I'm not particularly keen on
mandating particular non-obvious on-disk encodings as part of the Telepathy
spec, particularly if they're not just a cache/optimization.

(I consider the Avatars1 proposal - one file per avatar and one per MIME type -
to be an "obvious" on-disk encoding, so it gets away with it.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.