[Bug 32053] Add a TpContactSearch proxy object

[bugzilla-daemon at freedesktop.org]

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

--- Comment #6 from Emilio Pozuelo Monfort <pochu27 at gmail.com> 2010-12-06 05:44:20 PST ---
(In reply to comment #5)
> (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.

So we can search on random servers on e.g. XMPP? sounds good.

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

I'm not familiar with that.

> - GInitable maybe ?

This seems to be synchronous, no? That wouldn't work for us. Otherwise it seems
nice.

The asynchronous API sounds good too.

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

Yes, could be. And sounds nicer.

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

So normally the callback will return TRUE to get more contacts, until it gets
an empty GList, in which case it will return FALSE? Sounds good to me.

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

Not sure about this. We discussed this on IRC and having to create a new object
for every search didn't sound very friendly. Though if it's easy I could leave
with that... Opinions?

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