[Bug 48210] Could TpBaseChannel be more flexible?

[bugzilla-daemon at freedesktop.org]

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

--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-04-04 04:31:42 PDT ---
(In reply to comment #0)
> So when the MUC channel is closed, but should remain open behind the scenes:
> 
> > tp_svc_channel_emit_closed (chan);
> > tp_base_channel_unregister ((TpBaseChannel *) chan);

API users shouldn't have to deal with the Closed signal directly. See also the
way the TpBaseChannel API tries to make dealing with Destroyable (and
respawning channels) easier.

What you basically want, I think, is a way to "come back" from
tp_base_channel_destroyed(), plus some way to have the channel start off in a
"disappeared" state? (Perhaps just not calling register, or setting
channel-destroyed to TRUE initially?)

Perhaps tp_base_channel_disappear() would be a better name than
tp_base_channel_destroyed() if you plan to come back, even if the effect is
pretty similar.

TpExportableChannel::closed will also need augmenting with some sort of
"pretend to close" and "come back" functionality, because it currently assumes
that the two happen simultaneously.

> and when we want the channel to reappear:
> 
> > tp_base_channel_reset ((TpBaseChannel *) chan, initiator_handle, requested);
> > tp_base_channel_register ((TpBaseChannel *) chan);
> > /* notify the channel manager so it can _emit_new_channel */

tp_base_channel_appear (channel, initiator, requested) which does all three?

Then tp_base_channel_reopened() would become equivalent to an atomic pair of
disappear() and appear(initiator, FALSE). (We assume that the initiator is
someone other than us, because reopened() is designed for the "respawned by a
message" case.)

> However, this makes TpBaseChannel pretty easy to abuse and get wrong

Indeed, but perhaps the API can help users out enough that they'll get it
right.

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