Now that handles don't expire (at least on some CMs), it's possible to have this logic for e.g. receiving messages and getting Group changes: * if the connection has immortal handles and we know the handle and we know the identifier, make a TpContact synchronously (needs new API, see branch) and signal the event straight away * else if we have a cached TpContact (needs new API, not yet written) signal the event straight away * else make a TpContact asynchronously and signal the event later; if you don't like your messages being re-ordered, upgrade your CM('s library) Probably blocks Bug #27175, certainly blocks Bug #29531.
Branch looks good but I have a few questions. I guess we'll make immortable handles mandatory in TP 1.0. Then this function could be renamed tp_connection_dup_contact_for_handle(), adds a note somewhere to not forget? (In reply to comment #0) > * if the connection has immortal handles and we know the handle and we know the > identifier, make a TpContact synchronously (needs new API, see branch) and > signal the event straight away How can a client easily check if a handle is known? > * else if we have a cached TpContact (needs new API, not yet written) signal > the event straight away I guess TpTextChannel should use this one as all it gets is the sender handle from the CM, right ? > * else make a TpContact asynchronously and signal the event later; if you don't > like your messages being re-ordered, upgrade your CM('s library) > > Probably blocks Bug #27175, certainly blocks Bug #29531. Should we make immortal handles a requierement for TpTextChannel? Factories could create a TpTextChannel only if the connection implements immortal handles but that assumes that the TpConnection passed to tp_client_channel_factory_create_channel() as CORE ready so we can check.
(In reply to comment #1) > I guess we'll make immortable handles mandatory in TP 1.0. Then this function > could be renamed tp_connection_dup_contact_for_handle(), adds a note somewhere > to not forget? No need, the current plan is to get rid of handles altogether (Bug #23156). > (In reply to comment #0) > How can a client easily check if a handle is known? For instance, if you receive MembersChangedDetailed with a complete contact-ids hint, or a Message_Part[] with both message-sender and message-sender-id in its header, then you know that the handle corresponds to the ID. > > * else if we have a cached TpContact (needs new API, not yet written) signal > > the event straight away > > I guess TpTextChannel should use this one as all it gets is the sender handle > from the CM, right ? I added message-sender-id to Messages. We should make all CMs emit it; for CMs that fail to do, the fallback path is to delay message processing, and if you don't like getting your messages re-ordered you should fix your CM. > Should we make immortal handles a requierement for TpTextChannel? Factories > could create a TpTextChannel only if the connection implements immortal handles > but that assumes that the TpConnection passed to > tp_client_channel_factory_create_channel() as CORE ready so we can check. I'd be inclined to say no: re-ordering messages is less bad than complete inability to deal with the channel.
Fair enough. ++
Fixed in 0.13.8
While trying to make more use of TpContact for Group channels, I realised that this isn't the most useful API it could be. See branch for an improved version, with tests.
Isn't a bit overkill to call it _if_possible ? Most of the API are trying to do their job as best as they can. :) Furthermore, the _if_possible will go away once immortable handles will become mandatory.
We discussed this on IRC and I still think the suffix is necessary, to emphasise that until Telepathy 1.0, calling that method and bailing out if it returns NULL isn't really acceptable. Fixed in 0.13.9 (not 0.13.8 as I mistakenly claimed above).
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.