[Bug 30617] TpChannel: high level API to close/leave channel

[bugzilla-daemon at freedesktop.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|telepathy-bugs at lists.freede |guillaume.desmottes at collabo
                   |sktop.org                   |ra.co.uk

--- Comment #5 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-11-08 05:32:17 PST ---
The API here looks right. I'm a bit reluctant to merge this without a clear
picture of how it relates to Call, though...

(i.e. will it still make sense to use a Group_Change_Reason in the Call world?)

-------------------

Implementation:

> +  g_simple_async_result_complete (result);

This should be in an idle: TpProxy doesn't guarantee delayed callback calls,
sadly.

> + * for any reason we can properly leave the channel, we close it.

"we can't properly"

I think it'd be useful if tp_channel_leave_async() supported a NULL callback?

> +  /* Create service-side tube channel object */

tube? :-)

> +  test->chan_room_service = g_object_new (

There's a test-specific wrapper for g_object_new which suppresses valgrind
warnings about the "leaked" class struct.

> +  /* FIXME: This is crack a chan_room_service is actually not a
> +   * TpTestsTextChannelNull */
> +  props = tp_tests_text_channel_get_props (
> +      (TpTestsTextChannelNull *) test->chan_room_service);

Er, yes, that...

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