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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #7 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-04-16 03:29:08 PDT ---
(In reply to comment #6)
> > b) Should start_listing_async() be renamed to list_async() or something,
> > complete when the list operation is done (ListingRooms goes back to FALSE) and
> > return the  list of TpRoomInfo found. User will still have the got-rooms signal
> > to display rooms while they are found, but having a list API to returning any
> > result looks a bit weird to me.
> 
> Good point. I would also be fine if you did this list_async() rename.

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.

I agree that start_listing_async() is relatively useless (it returning
successfully is basically meaningless), but renaming to list_async() without
returning the GList<TpRoomInfo> would indeed seem pretty strange.

Having two ways to access exactly the same information with different timing
also seems odd to me. At the moment, got-rooms is the only way, which seems
good.

On the other hand, "most" API users will just be turning each room into a row
in a GtkListModel as it arrives...

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

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