[Bug 32023] add a way to make a TpContact synchronously, if the CM is modern

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32023

--- Comment #2 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-12-02 04:33:01 PST ---
(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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.