[Bug 62378] Offline contact caching

[bugzilla-daemon at freedesktop.org]

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

--- Comment #5 from Xavier Claessens <xclaesse at gmail.com> ---
(In reply to comment #4)
> (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.

Ok.

> 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).

IRC does not need offline caching, it makes no sense to have a roster there,
AFAIK.

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

Goals are in the initial report.

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

This could be a solution indeed.

> 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).

Folks is a library, it is not a place to do such thing. Unless you want all
processes to know everything about all contacts and write on disk at the same
time. I believe folks need significant changes to be useful. Its performance
make it simply not a solution to any problem.

I think the CM is the best place to do offline cache, because it's the only
process that should know everything about all contacts.

> (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.

Right, so it is good enough for tp-glib, and not if we want to interop with
tp-qt.

otoh, one thing I like with using GVariant file format, is all processes
needing to know about offline contacts can use a GMappedFile and GVariant won't
do any copy of the data.

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