[Bug 26785] PendingMessagesRemoved signal should be more informative

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=26785





--- Comment #5 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2010-03-02 04:16:06 PST ---

(In reply to comment #3)
> (In reply to comment #2)
> > An observer wants to keep track of the receiving and ACK times for every
> > message it can.
> 
> This can't reliably be done across an observer exit. Channels can't necessarily
> be matched by object path over time

Perhaps a better way to express this is that pending message IDs are, by their
very nature, temporary, so old pending-message-IDs are likely to have
"expired".

If the Observer exits while Text channels exist, there is an unavoidable window
(time before it restarts, connects to D-Bus and catches up) in which it will
miss:

* any new messages that are acknowledged during that same window
* any acknowledgements (PMR) that are sent during that same window

The practical effect of this is that after a logger crash, you might have
messages missing from your log, and you might have messages you've seen that
are still marked as unseen.

The effect of the PMR signal only carrying message IDs is that the window of
acknowledgement loss lasts slightly longer (until state recovery finishes),
i.e. the number of messages wrongly marked as unseen is greater. I don't think
this is a practical problem.

(In reply to comment #4)
> From this point of view, TP should create its own unique token or give the
> possibility to clients to obtain a trustable and unique token, even if its
> uniqueness is only local to TP (ie not passed by the protocol).

What you ideally want for a database is a token that maps 1:1 to an abstract
message (the "message-token" header in telepathy-spec), but unfortunately
that's not possible in most protocols. The best we can do is a token such that
each token uniquely identifies one abstract message, but each abstract message
might have more than one such token. I can't think of a good name for that
right now; can you?

Ways the CM could achieve that "next best thing" include:

* put a token with those semantics on each message (i.e. generate a large
number of UUIDs)

* put a different UUID on each Channel instance, so that the tuple (channel
UUID, pending message ID) is unique over time

In XMPP MUCs, a few previous messages, which you may or may not already have
seen, are replayed as "scrollback" when you join. The scrollback message's
timestamp doesn't necessarily exactly match the timestamp of the original
message, if you first saw it "live", so it's not possible for the CM (which has
no log of previous sessions in this MUC) to determine whether it's been seen
already.

It's also possible to get duplicate messages in any protocol with explicit
acknowledgement, if the explicit acknowledgement gets lost: SMSs, some
configurations of XMPP and SIP, and probably Skype. SMSs are particularly
frustrating since they have a small identifier with poor uniqueness (1 byte).

To eliminate duplicates of "the same" message, either TPL should eliminate them
when they're logged (keeping only the version that was already in the database,
or something), or clients should eliminate them when reading from the TPL
database. This will require several database operations, probably.

To make it easier to eliminate duplicates, CMs could put the
possibly-non-unique protocol token in a new Message[0] field (protocol-token or
something), defined such that messages with a different protocol-token are
different, but messages with the same protocol-token may be the same or
different. It's not enough information for you on its own, but at least it can
be an input to your duplicate-elimination heuristic.

> Currently TPL is using a similar function, for internal use, hasing the triple
> (channel path, pending msg id, timestamp).
> The triple should uniquely identify, in TP at any time, a message.

Not really, consider this:

* clock ticks, 11:59:59 -> 12:00:00
* message #1 is received
* channel /foo closes
* channel /foo opens
* a new message #1 is received
* clock ticks, 12:00:00 -> 12:00:01

The per-message or per-channel UUID I proposed above would both solve this,
though.


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