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: http://git.collabora.co.uk/?p=user/xclaesse/telepathy-glib.git;a=shortlog;h=refs/heads/channel-id
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. http://git.collabora.co.uk/?p=user/smcv/telepathy-glib-smcv.git;a=shortlog;h=refs/heads/null-ident
(In reply to comment #6) > How's this? I'd particularly appreciate review from Will and Xavier, who've > looked at this before. > > http://git.collabora.co.uk/?p=user/smcv/telepathy-glib-smcv.git;a=shortlog;h=refs/heads/null-ident Looks fine.
Merged, will be in 0.11.4.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.