[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