[Bug 30338] TpRoomList - High level API for RoomList channel

[bugzilla-daemon at freedesktop.org]

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

--- Comment #8 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2012-04-16 06:12:08 PDT ---
(In reply to comment #7)
> I'm vaguely against this; the reason why the RoomList API is so odd is that the
> list can be pretty huge (IRC, or XMPP on a big server that is everyone's
> default chatroom host), and having list_async() return the complete list means
> we have to hold everything in a temporary list (GQueue?) inside telepathy-glib
> for the duration of the operation - even if, for instance, the caller is
> performing client-side filtering on got-rooms and throwing away most of them.

Fair enough.

> I wonder whether we could do this differently by having the methods pretend to
> be synchronous? Something like this (assume the usual C boilerplate and
> TpRoomList* first argument):
> 
>     void start()
>     signal room-list-failed(GError)  /* or even use invalidated? */
>     signal got-rooms(...)
>     void stop()
> 
> stop being void is a bit odd, but on the other hand, why would you ever want to
> know how long it took? And, if you fail to stop it, what will you ever do about
> it? (Destroy() falling back to Close() if unimplemented? ... but stop() could
> do that automatically, perhaps.)

I like this approach. I think I'd make call Destroy/Close if something go wrong
(start/stop failing as there is no much you can do in that case anyway) so
invalidated will be fired.

But do we really need stop()? User can just close/destroy the channel once he's
the done with it.

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