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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #4 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2010-09-23 04:31:01 PDT ---
(In reply to comment #3)
> I'd personally give this low priority: if you want to do a straightforward port
> from Empathy you're welcome to do so, but text and tubes channels are more
> important IMO.

Sure, I mostly opened the bug for completion purpose.
Oth, I'd really like to move forward on bug #29973 and we can't really merge it
before we have a least on TpChannel subclass to proof use it.
As TpStreamTube and TpTextChannel are not that trivial maybe it could be this
one which is less controversial? Oth, that's not true anymore if we want to
change the spec first.

> (In reply to comment #1)
> > TpRoomList * tp_room_list_new (TpConnection *conn,
> 
> Perhaps TpRoomListChannel. I'm not sure whether we should enforce a "Channel"
> suffix for all tp-glib TpChannel subclasses.
> 
> (Precedent: in telepathy-qt4, I initially only added Channel where the channel
> type didn't make sense as a noun - so we had Tp::TextChannel and
> Tp::StreamedMediaChannel, but Tp::RoomList and Tp::StreamTube - but Andre
> decided it was better to add Channel to all of them, consistently, and that's
> now the convention.)

I don't really care but staying coherent and "sync" with tp-qt4 could be good
enough arguments to always have "Channel" in the name.

> > gboolean tp_room_list_get_listing (TpRoomList *self);
> 
> This is mutable, so it'll need a Feature if you want it.

Yep, see the other comment :)

> > void tp_room_list_start_listing_async (TpRoomList *self,
> >     GAsyncReadyCallback callback,
> >     gpointer user_data);
> > 
> > gboolean tp_room_list_start_listing_finish (TpRoomList *self,
> >     GAsyncResult *result,
> >     GError **error);
> 
> We should document in the spec whether ListRooms raises an error if this
> channel is already in the middle of listing rooms. I think we should define
> Create semantics as the only ones that make sense and delete the possibility of
> the channel being a per-connection singleton, tbh (i.e. make it look like
> ContactSearch) - does Empathy actually cope with being given a room list that's
> already listing?

Yeah that makes sense. Empathy does check if the channel is already listing but
I think this change would be sane.

> > got-rooms (GPtrArray *rooms) with rooms containing TP_STRUCT_TYPE_ROOM_INFO
> > Or maybe we should have a small TpRoomInfo object?
> 
> A TpRoomInfo struct or small-GObject, please:
> 
>     TpRoomInfo *tp_room_info_new (GValueArray *dbus_glib_struct);
> or perhaps
>     TpRoomInfo *tp_room_info_new (TpHandle handle, const gchar *ctype,
> GHashTable *asv);
> 
> and in either case
> 
>     TpHandle tp_room_info_get_handle (TpRoomInfo *self);
>     const gchar *tp_room_info_get_channel_type (TpRoomInfo *self);
>     const gchar *tp_room_info_get_handle_name (TpRoomInfo *self);
>     const gchar *tp_room_info_get_name (TpRoomInfo *self);
>     const gchar *tp_room_info_get_description (TpRoomInfo *self);
>     const gchar *tp_room_info_get_subject (TpRoomInfo *self);
>     guint tp_room_info_get_members (TpRoomInfo *self, gboolean *known);
>     /* "password" on D-Bus */
>     gboolean tp_room_info_get_requires_password (TpRoomInfo *self, gboolean
> *known);
>     gboolean tp_room_info_get_invite_only (TpRoomInfo *self, gboolean *known);
>     const gchar *tp_room_info_get_room_id (TpRoomInfo *self);
>     const gchar *tp_room_info_get_server (TpRoomInfo *self);
> 
> All the string accessors would have tp_asv_get_string() semantics. The int and
> boolean accessors would have tp_asv_get_uint32 semantics, with valid mapped to
> known.

I'd vote for a small object because from my experience each time we have this
kind of thing as a struct we end up at some point saying "shit it would easier
to use if it was a proper object".

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