[Bug 29531] high-level API for text channels

[bugzilla-daemon at freedesktop.org]

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

--- Comment #17 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2010-12-10 05:13:31 PST ---
(In reply to comment #16)
> (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".

Ok, I changed that.

> 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

Humm, how can I detect such case? Should I always treat it as it when I get a
Message without message-sender-id on a connection not having immortal handles?

> 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...

I changed the code to always use ID, when possible.

> 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.

ok.

> > 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.

Agreed. Are you going to do the spec change or do you want me to?

> > 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.

We could add the preparation of CONNECTED in the CORE preparation of the
channel.

> (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.)

I think that's fine, as long it's just the fallback case.

-- 
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.