[Telepathy] The semantics of the Sent signal in multi-user chats

[Will Thompson]

Hi,

While implementing the Messages interface, the exact semantics of the
Sent and SendError signals on Text channels (and MessageSent and
receiving delivery reports on Messages, respectively) have come into
question. Currently, the specification for Channel.Type.Text says:

> Sending messages can be requested using the Send method, which will
> return successfully and emit the Sent signal when the message has been
> delivered to the server, or return an error with no signal emission if
> there is a failure. If a message is sent but delivery of the message
> later fails, this is indicated with the SendError signal.
>

So, correct CMs currently should emit Sent at the same time as returning
from Send, and later emit SendError if an error report comes in.
Previously, the spec said that exactly one of Sent and SendError should
be emitted, but that's not possible on (for instance) 1-1 conversations
on XMPP: you get no confirmation of messages having been successfully
sent, so you can't delay the emission of Sent. The spec was changed in
0.17.3 because of the impracticality of the previous requirement, and
because most CMs have always done what the current spec says.

However, Gabble MUCs (and allegedly all Salut channels) currently obey
the old spec. In an XMPP MUC, the server echoes messages you send back
to you; Gabble returns from Send immediately, then emits Sent only when
the messages you send are echoed to you, and SendError when the MUC
server sends you an error stanza. This is inconsistent with 1-1
channels, Idle's IRC channels, and the spec.

We've discussed this at some length over the last few days, and have
come to the conclusion that Sent is being overloaded to mean two
different things: “this message has been submitted”, and “this message
has been successfully sent”. Sent should only mean the former, and there
should be a separate notification for messages having been successfully
sent/delivered (where such a notification is permitted by the protocol).
In the glorious future of the Messages interface, that separate
notification is a delivery report with delivery-status: Delivered. So,
sending a message in an XMPP MUC would look like this:

    * Client calls SendMessage().
    * SendMessage() returns; MessageSent (and Sent on Channel.Type.Text)
      is emitted immediately.
    * Time passes; MessageReceived() might be emitted for incoming messages.
    * MessageReceived() is emitted with a delivery report saying that
      your message was delivered.


Under this scheme, MessageReceived() always represents the order that
messages are seen by other MUC participants.

Currently, Empathy only writes messages to the scrollback when Sent is
emitted, which corresponds to the order that messages were sent out by
the MUC. If this change were made in Gabble, unmodified Empathies would
write messages that you send in chats to the scrollback immediately,
rather than at the time they are sent out to all users by the MUC; to
keep the current behaviour, it could request delivery reports for
channels which have the
Delivery_Reporting_Support_Flag_Receive_Successes flag set, and then
only write sent messages to the scrollback when reports are received.
Or, if the client doesn't mind about a total ordering of messages, it
can ignore delivery reports and just write your own messages to the
scrollback when MessageSent is emitted, and other people's messages on
MessageReceived.

This change would also have the benefit that messages sent to MUCs which
never actually make it would be logged by an observer listening to the
MessageSent signal; such an observer could also pay attention to
delivery reports in order to log that a message didn't reach its
destination. Currently, if your connection breaks between you sending
the message and the server echoing the message back to you, it is never
mentioned by any signal.

Do people think this sounds sane? Do we think the slight
backward-compatibility break is acceptable?

Thanks,

-- 
Will


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20081022/ecd25d2c/attachment.pgp