Hi, On 18/11/10 21:03, mikhail.zabal...@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 _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy