This signal is duplicated. I'd just remove the one on Content.
Otherwise, I would add a reason on Content.Removed.
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.
Author: Olivier Crête <firstname.lastname@example.org>
Date: Wed Dec 14 16:21:28 2011 -0500
Remove the duplicated Removed() signal on the Call.Content