[Bug 13350] ContactInfo: implement and undraft

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=13350





--- Comment #3 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2010-02-26 05:17:17 PST ---
(In reply to comment #2)
> Hmm. I just discussed some issues with this spec with Marco and Sjoerd, and
> discovered an unmerged branch from the last time I discussed this with Marco.
> The spec branch is at
> <http://git.collabora.co.uk/?p=user/wjt/telepathy-spec-wjt.git;a=shortlog;h=refs/heads/contact-info-network-traffic>

Looks good, except:

+        info to be updated, but MUST NOT do so without direct user action or
to
+        refresh its own cache after a number of days.</p>

Do you mean that clients may refresh their caches automatically after a number
of days, or that this is forbidden? The current text reads as though it's
forbidden. Assuming you want to allow cache refreshes, how about this?

"... but MUST NOT do so unless this is either in response to direct user
action, or to refresh its own cache after a number of days"

> Sjoerd also suggested adding tokens to ContactInfo, akin to avatar tokens. This
> would allow the CM to cache them forever without its memory usage expanding out
> of control. Also, a similar issue exists with clients being able to miss
> transient information exists on the EmailNotification interface; we could use a
> general solution.

How would tokens help, assuming a protocol like XMPP where we don't have
protocol-level tokens?

Additional changes:

Marco has requested that the network-traffic-provoking part of GetContactInfo
is replaced by something like a fire-and-forget RefreshContactInfo(au:
Contacts) -> void, which polls all of those contacts' info and emits
ContactInfoChanged signals. This seems easy to do.

Based on implementation experience in Gabble, I'd also like to suggest:

* SupportedFields and ContactInfoFlags should have the same semantics as
SupportedAvatarMIMETypes and friends: they can change without notice during the
Connection's early lifetime, but must be "frozen" by the time the Connection
moves to CONNECTED state. (Rationale: Gabble can realise we're connected to a
Google server, and omit most of its supported vCard fields; or it can realise
we're connected to Facebook, and clear the Can_Set flag entirely)

* For interop, it would be nice to have a more elaborate example of ORG:
perhaps the Wee Ninja should have "ORG:Collabora, Ltd.;Management
Division;Human Resources\; Company Policy Enforcement" or something, to
demonstrate nested org.units)

* Similarly, we should include LABEL (preformatted address) in the list of
well-known vCard fields, and give the Wee Ninja's address label (see the Gabble
regression tests for details)


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.