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

[bugzilla-daemon at freedesktop.org]

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

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|medium                      |low

--- Comment #3 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-09-23 03:27:28 PDT ---
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.

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

> gboolean tp_room_list_get_listing (TpRoomList *self);

This is mutable, so it'll need a Feature if you want it.

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

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

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