[Bug 29531] high-level API for text channels

[bugzilla-daemon at freedesktop.org]

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

--- Comment #16 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-12-10 04:02:41 PST ---
(In reply to comment #14)
> When fetching pending messages we ignore [messages without a sender]

I think it should be possible to receive messages with an unspecified sender
(handle 0), with the API being "the handle is 0 or omitted, and the contact is
NULL". We could use them for messages from the server, from the chatroom or
from a contact who could not be identified, for instance. message-sender says
"If 0 or omitted, the contact who sent the message could not be determined".

There is one pathological case where we might get messages with a nonzero
handle but be forced to omit the sender contact:

* the CM is old, and so doesn't have immortal handles
* the CM is old, and so doesn't specify message-sender-id
* the handle was valid when we received the message, but became invalid before
we could do HoldHandles on it

I think it'd be OK to deal with that by removing the sender handle (which is
now meaningless).

If the CM doesn't have immortal handles, but does specify message-sender-id,
it's slightly more reliable to do the "get a contact" round-trip in terms of
the ID instead of the handle. You might not get the same handle back in
pathological cases, in which case you need to edit the message-sender...

Hmm, I think this means we need to change _tp_signalled_message_new slightly,
so that instead of asserting that the sender contact and the headers are
consistent, it trusts the contact implicitly, and edits the headers to match?
I'll do a mini-branch.

> a) Make mandatory to have message-sender[-id] define in messages announced in
> MessageSent. Then we can use this handle and get a TpContact from it.

I think I'd like to add this to the spec on general principles - sent messages
should be as close as possible to what the peer receives - but ideally
TpTextChannel shouldn't rely on it.

> b) If channel implements Group, use tp_channel_group_get_self_handle(). Then we
> need to prepare the GROUP feature, so we should have a
> TP_TEXT_CHANNEL_FEATURE_MESSAGE_SENT feature preparing GROUP if needed.

If we do (a), then it's OK for the fallback code in telepathy-glib to be a
little less pedantic, so perhaps it could use the TpConnection:self-contact
that I just added, and ignore the possibility of a channel-specific self
handle?

That may still need to be async, because self-contact requires the CONNECTED
feature on the connection, and we can theoretically start handling a channel
before we've fully inspected the Connection.

(If you particularly want the channel-specific contact, I'm working on API to
make every Group TpChannel guarantee that its contacts are available as
TpContact objects.)

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