TpChannel:identifier for anonymous channels is NULL if the underlying channel doesn't implement the TargetID property, but "" if it does. TpChannel should be consistent with whatever TpContact:identifier does.
Branch fixing this:
Too risky for a stable branch. 0.9 material.
Xavier, is this branch still what you want / suitable for review?
What TpContact does turns out to be irrelevant, since a TpContact always has a valid identifier.
Xavier's branch implements the following semantics:
* if identifier is not known yet, return NULL
* if identifier is known to be irrelevant due to TargetHandleType = None, return ""
This is consistent with the previous behaviour of channels with TargetID support (i.e. increasingly many). However, I wonder whether returning a non-NULL string from the start makes more sense?
I'm unsure about the appropriateness of the implementation: getting the immutable properties dict will still yield an unspecified TargetID, but we can do better. _tp_channel_get_identifier() already has a special case for THT=None; that special case could just be extended to set the TargetID using _tp_channel_maybe_set_identifier before continuing.
From a quick skim through Empathy, I think we're right to avoid NULL; many callers effectively assume a non-NULL return. I'll do an alternative branch.
How's this? I'd particularly appreciate review from Will and Xavier, who've looked at this before.
(In reply to comment #6)
> How's this? I'd particularly appreciate review from Will and Xavier, who've
> looked at this before.
Merged, will be in 0.11.4.