[Telepathy] Massively complicating Folks for greater future

Philip Withnall philip at tecnocode.co.uk
Mon Mar 28 10:57:46 PDT 2011


On Mon, 2011-03-28 at 13:58 +0100, Will Thompson wrote:
> Hi,
> 
> On 18/11/10 21:03, mikhail.zabaluev at nokia.com wrote:
> > I have created a branch on Folks to propose a more scalable API:
> > 
> > http://git.collabora.co.uk/?p=user/zabaluev/folks.git;a=shortlog;h=refs/heads/views
> 
> So, Travis, Philip and myself had a chat on #telepathy on Thursday (from
> 1810 to 1930 UTC if you have logs;
> http://people.collabora.co.uk/~wjt/tmp/folks-search-and-filtering is the
> poorly-formatted log I got from irssi) about this. The ongoing work on
> exposing information from libsocialweb in Folks has added another case
> where it's expensive to fetch excess information, and also where it's
> impossible to keep it up-to-date without polling.
> 
> We broadly think that Folks needs the following additions and changes:
> 
> • An API for specifying queries. Mikhail's API proposal (above) look
> like the right kind of level of simplicity for this: exposing specific
> implementations of a Query interface for attributes which make sense to
> query on, like contact ID, phone number, birthdays in the next week,
> etc.; rather than some kind of maximally-general query language for
> predicates on contact attributes or something.
> • Read-only, live-updated views of the results of those queries, as the
> IndividualList sketch provides; plus…
> • A way to explicitly tell one of these views to refresh its poll-only
> data. The latter allows for the case where, for instance, the user knows
> by some out-of-band means that a contact has changed their phone number,
> and they want to force a refresh even though the local cache doesn't
> seem stale.
> • Specifying interfaces that the application making the query is
> interested in. Again, Misha's sketch provides this.
> • Extending the PersonaStore interface to relay all this information to
> the backends for different sources. (Some backends can disregard most of
> this information: for views on local stores with change notification,
> refresh is meaningless, for instance.)
> • Finally, obviously the backends for libsocialweb and possibly other
> sources need to be updated to make use of this information.
> 
> We think that the same human retrieved via two different IndividualLists
> should be represented by the same object. This means that
> IndividualLists can return Individuals with more information than was
> requested up-front, because some other query asked for different
> information. I don't see this as a problem: if the information's
> available, there's no extra cost to showing it.
> 
> Selectively retrieving expensive information should have no impact on
> auto-linking: I think it's a safe bet that only very static information
> (like names, email addresses, and so on) is useful for auto-linking.

As Travis and I agreed (after you'd left, I think), a reasonable way to
do this is to require that backends *always* retrieve the values of
properties in their personas which have been defined as linkable (i.e.
properties which are listed in Persona.linkable_properties).

This guarantees that all the necessary data is always available for
linking, so the correct links are always made.

Handily enough, the only properties which are listed as linkable at the
moment are particularly static ones.

Philip

> Thoughts?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/telepathy/attachments/20110328/ec969ad7/attachment.pgp>


More information about the telepathy mailing list