[Telepathy] Massively complicating Folks for greater future

[Will Thompson]

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.

Thoughts?
-- 
Will