[Bug 35883] Add support for text message delivery report

[bugzilla-daemon at freedesktop.org]

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

--- Comment #2 from David Laban <david.laban at collabora.co.uk> 2011-04-25 08:12:28 PDT ---
progress is at:
http://cgit.freedesktop.org/~alsuren/telepathy-logger/log/?h=delivery-report

Things I've noticed during implementation so far:

http://telepathy.freedesktop.org/spec/Channel_Interface_Messages.html#Simple-Type:Protocol_Message_Token
says that message-token is not guaranteed to be unique.

The hard use-case is:
* send SMS (a)
** text = hello
** message-token = 123
** timestamp = 1

* send SMS (b)
** text = goodbye
** message-token = 123
** timestamp = 2

* Receive delivery report for (a)
** message-token = 123
** timestamp = 3

* Receive delivery report for (b)
** message-token = 123
** timestamp = 4

The heuristic suggested in the spec for this case (colliding ids and no other
information) is to assign the delivery report to the most recent message with
that id. This would mean that SMS (a) would not be marked as acknowledged.

If we use the following algorithm, I think it could work a bit better:

* Read the delivery report xml file, and create a map (unpaired_reports) from
message-token to list of delivery-reports (sorted by date; note that this will
be one-element long most of the time)

* Read the text xml file
* For each text event:
** If the message-token is in unpaired_reports
  and the report timestamp is after the message timestamp
  and (the text matches up with the echo or the echo is null)
*** then match the report to the text event and delete it from pending
** If the message-token is not in unpaired_reports, look in the reports xml
file for the next day (but don't put any new entries in unpaired_reports).

* If there are still entries in delivery-reports that are unmatched at the end,
add them into the conversation at the appropriate point using their echos
(alternatively, we could synthesise text-events from report-events while we are
writing the logs, and just log a warning + throw the message away if there are
left-overs at this point. Thoughts?).

problems with this approach:
* if message-tokens are non-unique and reports are returned out-of-order, they
will be matched up incorrectly (so if a message goes missing, there's a chance
that the wrong one will be marked missing).
* if message-tokens are non-unique, and duplicates exist then we've lost.
(note that I can't think of an approach that won't have this problem)

Benefits of this algorithm:
* It's the same as the one Nicolas suggests, but it explicitly models
collisions (Yes we are building a collision-resistant data structure within a
collision-resistant hash table. I know.)
* Rather than having just a bool for confirmed/not, we have a link to the
confirmation event (so you can use that timestamp if you want)
* We can use the same kind of link for superseded-by/supersedes.

Questions:
* Did you imagine the xml files for reports/edits to be grouped by arrival date
or by the date of the original messages they relate to? (I've assumed arrival
date above, but actually original-message-date might make more sense?)
* Should we synthesise and log-to-disk text-events from report-events while we
are writing the logs, and just log a warning + throw the message away if there
are left-overs when we're done reading the logs back? (again, not sure how to
deal with the change-of-day corner case).

I will continue work tomorrow, but design input is welcome.

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