[Bug 48210] Could TpBaseChannel be more flexible?

[bugzilla-daemon at freedesktop.org]

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

--- Comment #2 from Jonny Lamb <jonny.lamb at collabora.co.uk> 2012-04-04 15:55:48 PDT ---
(In reply to comment #1)
> 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.

Right, but we want to make sure there's a distinction between the channel
having disappeared temporarily or disappeared for good.

We do want a channel, when unregistered, to emit Closed, but we also want a way
for channel managers to ask "is this actually closed, should I unref it, or
not?"

If we used _destroyed() then where would the distinction be? I kind of like
what I've done in that destroyed ~= disposed, in that you can never come back
from destroyed (hence the name).

So I'm a little confused as to what exactly you're counter-proposing here?

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