[Bug 30617] TpChannel: high level API to close/leave channel
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Mon Nov 8 15:00:51 CET 2010
https://bugs.freedesktop.org/show_bug.cgi?id=30617
--- Comment #6 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2010-11-08 06:00:51 PST ---
(In reply to comment #5)
> 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?)
Is there a spec bug for that question?
> > + g_simple_async_result_complete (result);
>
> This should be in an idle: TpProxy doesn't guarantee delayed callback calls,
> sadly.
How so? Both _complete are in a D-Bus method callback so it should be fine,
no?
> > + * for any reason we can properly leave the channel, we close it.
>
> "we can't properly"
fixed.
> I think it'd be useful if tp_channel_leave_async() supported a NULL callback?
Doesn't GSimpleAsyncResult already do that?
> > + /* Create service-side tube channel object */
>
> tube? :-)
Ooops; fixed.
> > + 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.
done.
> > + /* 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...
Oh I forgot that. From a quick look, tests doesn't seem to rely on it leaving
in the past so I'll port it to TpBaseChannel.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
More information about the telepathy-bugs
mailing list