[Bug 48210] Could TpBaseChannel be more flexible?

[bugzilla-daemon at freedesktop.org]

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

Jonny Lamb <jonny.lamb at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://cgit.freedesktop.org |http://cgit.freedesktop.org
                   |/~jonny/telepathy-glib/comm |/~jonny/telepathy-glib/log/
                   |it/?h=base-channel-disappea |?h=base-channel-disappear
                   |r                           |

--- Comment #12 from Jonny Lamb <jonny.lamb at collabora.co.uk> 2012-06-05 08:29:55 PDT ---
(In reply to comment #10)
> > + * // destoyed() must have been called; forget this channel
> 
> "destroyed"

Fixed.

> reopened[_with_requested] needs to re-register the object on D-Bus immediately
> after emitting closed, I think:
> 
>   if (!self->priv->registered)
>     tp_base_channel_register (self);
> 
> Otherwise, it can't implement any methods during its second life, and any
> signals that it emits during its second life will not reach D-Bus.

Yes, I was previously relying on the CM calling register, but this is better.

> This is sufficiently subtle that I would like a regression test in
> telepathy-glib.

Okay I added a simple test. Is this what you were thinking?

> I think this also emits ChannelClosed twice in this situation, which isn't
> hugely harmful but seems non-ideal:
[...]
> Two possible solutions, depending how much subtlety you're OK with piling onto
> the channel manager:
> 
> * require the channel manager to do:
> 
>     if (tp_base_channel_is_registered)
>       tp_channel_manager_emit_channel_closed (...)
> 
> * make tp_channel_manager_emit_channel_closed check for
>   TP_IS_BASE_CHANNEL and, if it is, suppress the signal
> 
> The former is more subtlety in CMs, the latter is arguably a layering
> violation.

I recommended the CM do the former.

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