[Bug 32053] Add a TpContactSearch proxy object

[bugzilla-daemon at freedesktop.org]

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

--- Comment #5 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2010-12-06 01:29:37 PST ---
(In reply to comment #3)
> > That would also use to get rid of the search-keys-changed signal.
> 
> How would you know the search keys then? The problem that I see with adding an
> API as you suggest below is that we need to query the search channel, but that
> may not be valid at the beginning. Or the API to query it could have a callback
> parameter which is called when the channel has been created and we know the
> search keys. Is that what you propose?

Humm you're right, that's bong.

What about something like that:

TpContactSearch * tp_contact_search_new (TpConnection *conn,
    const gchar *server);
with server == NULL meaning the default server.

void tp_contact_search_get_search_keys_async (TpContactSearch *self,
    GAsyncReadyCallback callback,
    gpointer user_data);

GHashTable * tp_contact_search_get_search_keys_finish (TpContactSearch *self,
    GAsyncResult *result,
    GError **error);

This will allow us to fetch the  AvailableSearchKeys property. Alternatives
include:
- Use a feature preparation mechanism (ala TpProxy)
- GInitable maybe ?

> > - It would be good to return an higher level structur for results. Maybe we
> > could use TpContact ?
> 
> Yeah, I guess I could do that. I'd need to translate the results from ids to
> TpContacts. Would returning a TpContact * const *contacts (as returned by
> tp_connection_get_contacts_by_id()) be acceptable, or would you put somewhere
> else? Does anybody else think this would be useful?

Maybe a GList of TpContact would be easier to deal with?

(In reply to comment #4)
> (In reply to comment #2)
> > - You don't use the More() method if needed.
> 
> I've just added a tp_contact_search_get_more_results() and a
> tp_contact_search_stop() methods. Should we also have a _get_status() method
> and a search-status-changed signal?

I'm not sure we should expose More() as you did.

What do you think of:

typedef gboolean (TpContactSearchCallback *) (TpContactSearch *self,
    const GError *error,
    GList *results,
    gpointer user_data);

void tp_contact_search_start (TpContactSearch *self,
    const GHashTable *keys,
    TpContactSearchCallback cb,
    gpointer user_data);

The callback could return TRUE if it wants more results. And an empty list as
results would mean that we the search is finished.

> Also wrt making TpContactSearch handle more than one search, I'm thinking of
> having a tp_contact_search_reset()  method that will create a new channel and
> invoke a callback when it's ready to make a new search. Does that sound
> sensible?


I'm not sure it's worth it. If this API is simple enough to use (which it
should), recreating a new TpContactSearch object shouldn't be a problem.


Smcv: input welcome, you're the API design guru here. :)

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