[Bug 32053] Add a TpContactSearch proxy object

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Dec 7 12:51:08 CET 2010


https://bugs.freedesktop.org/show_bug.cgi?id=32053

--- Comment #9 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-12-07 03:51:07 PST ---
I had a long comment explaining what the API should look like and why, but
Firefox ate it, so you're going to get a string of shorter comments instead.

(In reply to comment #2)
> - It would be good to return an higher level structur for results. Maybe we
> could use TpContact ?

No, I don't think that's appropriate. Instantiating a TpContact requires an
async round-trip to get the handle, and (in a recent tp-glib) locks the
(handle, identifier) pair into the CM's memory for the lifetime of the
Connection.

There also isn't a whole lot of overlap between the information TpContact
offers, and the information in a contact search result (which looks more like a
mini version of ContactInfo than anything else).

The extra information in a TpContact is relatively expensive to get for random
contacts (notably, the avatar), so we shouldn't get it for everyone in the
result set, only for contacts that the user expresses some sort of interest in
(clicks on, perhaps). I think that's out of scope for this object.

A high-level data structure would be good though: I think a
TpContactSearchResult GObject with an identifier, a GList<TpContactInfoField>
and optional convenience accessors for commonly-returned fields would be best.

Before offering convenience accessors you'd need to research what real
protocols actually give us - XMPP and libpurple would be good places to start.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.



More information about the telepathy-bugs mailing list