[Bug 37413] Clarify message edits (edit-timestamp and supersedes)

[bugzilla-daemon at freedesktop.org]

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

--- Comment #2 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2011-05-23 02:19:47 PDT ---
(In reply to comment #0)
> We need an additional "edit-timestamp" message header to make it clear that the
> timestamp on a message with supersedes set is that of the original message
> (this is required for efficiently locating the original message in e.g. the
> logger). Messing about with the semantics of received-timestamp is also not
> acceptable.

Is edit-timestamp the timestamp when the edit was sent, or when it was
received?

I'd have personally assumed that the edit would have its own (later) sent and
received timestamps (this would fit the conceptual model of a new message
superseding an old message, IMO), but if that causes practical problems, we
could have extra timestamps, as long as the spec is clear.

However, at the moment, received-timestamp is mandatory. If you retroactively
change its semantics to "the time at which we received the original message of
a supersedes chain", then that will have to be relaxed, because at the point
when you receive the superseding message, the CM is likely to have no idea when
you received the superseded message (it might even have been in a previous
session!).

The more I think about this, the more I think sent/received should refer to the
individual messages...

Of course, if the *logger* wants to present a timestamp with "original message
if possible" semantics, that's fine.

> The following case should be valid:
> message a;
> message b with supersedes = a;
> message c with supersedes = a;

Agreed. I think this is what XMPP does, in practice.

> The following should also be valid [...]
> message x gets lost
> message y with supersedes = x;
> message z with supersedes = x;

Yes.

> I would quite like to ban the following case [...]
> message a;
> message b with supersedes = a;
> message c with supersedes = b;

Only if we're absolutely sure that no protocol will ever implement
superseding/edits with this sort of structure. At the time that the CM receives
c, it's not at all guaranteed that it will remember a - so if the underlying
protocol represents edits like a linked list in this way, the CM has no choice
but to do the same.

If the *logger* wants to canonicalize the superseding structure into the first
form you mentioned, that might not be a bad idea, though - unlike the CM, it's
likely to have enough historical context to do that properly.

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