[Bug 32053] Add a TpContactSearch proxy object

[bugzilla-daemon at freedesktop.org]

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

--- Comment #10 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-12-07 03:56:23 PST ---
(In reply to comment #7)
> I think you should use a regular GSignal, rather than a callback. That allows
> more than one person to connect to the results if they're so interested.

I agree with the result but not with the reason :-)

I don't think it's worth offering API for multiple users of a contact search -
it's fine to have API of the form "you are expected to connect to all the
signals before calling go()", IMO.

However, GObject signals are better for bindability than plain callbacks, and
if we encapsulate each contact search result into an object then the signal
will be very easy to work with, so I think a signal
TpContactSearch::contact-found(TpContactSearchResult *) would be a good way to
do it.

> I also think you want results to appear in the list as they are returned by the
> server. Not all servers return the search results immediately, but trickle them
> out as they're found.

I agree. The D-Bus API is that results come in one at a time; I think trying to
batch them up in the high-level binding would be counter-productive.

> I think we should simply keep calling More() automatically until the user calls
> Stop() or the object is disposed.

I don't agree with this. If the server stops giving us results for a bit, it's
probably because if left to its own devices, it would flood us with an
excessive number of search hits; having use of the high-level API imply the
memory/bandwidth cost of the complete result set seems unwise. Hopefully the
contact the user wanted will be in the first few hits anyway...

-- 
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.