Add support for refreshing poll-based backends
@wjt
Submitted by Will Thompson Link to original bug (#643718)
Description
The services Folks has dealt with so far (well, IM…) generally has information pushed to the user by the service. This will change with the advent of the libsocialweb backend (bug 638280), for instance.
There are broadly two options for coping with these services: • have API for the application using Folks to explicitly request an update for a particular set of contacts; • poll every so often.
I guess the second can be implemented in terms of the first. :)
Which strategy is appropriate depends on the nature of the information being shown. For instance, a contact's birthday is unlikely to change frequently, so very sporadic polling (of the order of days/weeks) is enough to keep this reasonably up-to-date. At the other end of the spectrum, out-of-date status message or geolocation information is very noticeable to the user, so it would be preferable to poll reasonably frequently while the user is watching, and never when the user is not.
Relatedly, having smarter querying API in libfolks (rather than “here's a big set of individuals; search it”) would allow it to make more targeted requests to the server to explicitly refresh information, rather than having one big refresh() button.
(I note that contact information updates on Jabber are not pushed to the user, and Telepathy has API for explicitly requesting updates in this case: http://telepathy.freedesktop.org/spec/Connection_Interface_Contact_Info.html#Method:RefreshContactInfo. This is expensive in terms of bandwidth on XMPP: the contact information on the wire includes a base64-encoded copy of the contact's avatar …)
Version: git master