Bug 42932

Created attachment 54435 [details] [review]
Just remove Content.Removed, it's pointlessly duplicated

Lets just remove the duplicated signal

(In reply to comment #1)
> Lets just remove the duplicated signal

For the record, the reason for the duplicated signal was that if you only have a client-side proxy object for a Content and not for its parent Channel, you can't tell when the Content has gone away. I'd be happy for that to be resolved by "don't do that, then", though.

If the Content is implicitly considered to have gone away when the Channel closes (which I suspect it ought to) or when the Connection disconnects (which it certainly should), then TpCallContent needs to get a TpCallChannel and a TpConnection in its constructor anyway, to be able to connect to the appropriate invalidation signals.

Currently, in tp-glib, the TpCallContent proxy is created and destroyed by TpCallChannel.. but I see the point.. That said, it's probably easier to add signals later than remove them.

Note that TpCallContent's constructor is internal API, used only by TpCallChannel. It already gives the TpConnection but not the TpCallChannel. But that can be changed even without changing API. So if connection or channel goes away, and user keeps itself a ref to the content (why would it do that?) then it currently rely on the fact that the CM-side will also remove all contents from the bus to get the proxy invalidated (which TpBaseCallChannel does).

As a general rule, I'm in favor to remove things that we can add back later without breaking API rather than keeping useless stuff that we can't remover later.

Simon brings a good point to the table, but I say go for it.

Merge away.

commit 554e9a3c20cb3564e72bd3aa4e94e58977b9292f
Author: Olivier Crête <olivier.crete@collabora.com>
Date:   Wed Dec 14 16:21:28 2011 -0500

    Remove the duplicated Removed() signal on the Call.Content