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

[bugzilla-daemon at freedesktop.org]

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

David Laban <david.laban at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david.laban at collabora.co.uk

--- Comment #3 from David Laban <david.laban at collabora.co.uk> 2011-05-23 16:42:12 PDT ---
(In reply to comment #2)
> (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?
> 
Sent

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


When I think "message B supersedes message A", I expect message B to be the
same as message A, but with the bits that the remote member doesn't like
changed. I also don't think of an edit as a *separate* message as such (indeed,
the logger squashes superseded events together (returning them at the place in
the list where the original message was logged, with a method on the returned
object to get the chain of superseded events).

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

I probably wouldn't object to the edit having a "message-received" timestamp
that corresponds to when the *edit* was received. 

When I think of "message-sent", the main use that I can think for it is sorting
to view the conversation in the order that the remote user sees it (in case the
protocol doesn't guarantee message ordering).

This is one of the reasons why I suggested setting "message-sent" to that of
the original message (the other is that I find it more useful to visualise a
message and its edits as one message). "message-sent" is also optional for
incoming messages, so could be omitted if the CM doesn't know the date of the
original message.

The alternative to my original solution would be to have
"original-message-sent" and/or "original-message-received" optional headers.
Does this sound like a better idea? Also, are there any better names that we
could use?

> > 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.
> 
It is only the telepathy spec's choice of the word "supersedes" that suggests
that the banned form might be valid. If you think of the use-case: "I want to
edit message a... Oh no: still wrong. Let's try again." then the XMPP form is
very obviously the most natural one.

I'd give odds of at least 10:1 that it will *always* be possible for the CM to
represent message edits in the XMPP form. Marking the alternative as a banned
form for now makes writing/reviewing code a lot easier. If we have to
retrospectively allow the banned form then we probably have to go back and
test/audit all of our code anyway (implementing code which is resilient to both
is more complicated, and there are no CM implementations for people to test
against) so I don't think we actually gain anything by allowing it.

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