On Thu, 2010-11-18 at 22:03 +0100, mikhail.zabal...@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 _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy