[Telepathy] Massively complicating Folks for greater future

[Travis Reitter]

On Thu, 2010-11-18 at 22:03 +0100, mikhail.zabaluev at nokia.com wrote:
> Hi,
> 
> 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
> 
> The new classes are only stubs for discussion purposes. The main additions are IndividualList, providing an asynchronously retrieved live view on individuals matching a certain query, and an abstract Query class with some useful subclasses. The intent with queries is to broadly cover a few common cases, keeping the complexity of implementing queries in persona stores under control. For example, there would be only the OR-combining query to match string prefixes, and the matching should be case insensitive. If the clients want more restrictive matching (e.g. if it's in fact a QtMobility Contacts client using their overengineered query structures), they can filter the resulting list. Matching for a phone number is an interesting special case, which needs fuzzier heuristics to be applied and should perhaps ultimately be customizable.
> The public hash table of individuals in IndividualAggregator can be eventually deprecated, if we want support for more than a few dosen of contacts, and efficiently implement search-oriented backends.

Thanks for proposing this. At a high level, it looks good. I know how
useful it can be to have a query interface for contacts (we could use
this in Empathy's LiveSearch widget and Gnome Shell when we get around
to writing a search provider).

I've already thought of some Persona-fetching rate limiting to smooth
out the CPU and I/O loads after preparing the Aggregator with a few
hundred Personas (which even makes Empathy seemingly block for a couple
seconds on my laptop - though I haven't confirmed this is necessarily
Folks' fault). This would probably fit in well with Query support.

Other than that, though, it seems it could be a while before this would
let us improve performance. I would think it would only help if we can
push the query back into some of the Backends. And e-d-s and Tracker are
the only potential sources I can think of that would be able to support
this.

Still, this seems generally useful. So please file a bug and develop the
branch further. Tests would be greatly appreciated (especially if they
can suggest that queries would smooth out the initial CPU/IO spike).

Thanks,
-Travis