More TODO updates.

diff --git a/TODO.md b/TODO.md
index afb395240ffdd4e97bdacc51ce1183e2a08ec2d7..c3ab91ebbaa648a7c2a7aa248a9c9664c99ada5c 100644 (file)
--- a/TODO.md
+++ b/TODO.md
@@ -154,7 +154,60 @@ Real Mono, for those privileged users with a shell login, has a
 keystroke (F8) to read a disk file and insert it into the editor
 buffer. That might well be useful here too.
 
-## Better handling of updates and streaming
+## Better handling of updates
+
+### Cache invalidation
+
+We keep a cache of various kinds of record we've received from the
+server – `Status`, `Account`, etc. Things stay in our cache
+indefinitely, and we don't proactively try to retrieve updated
+versions of them, though we do update a cache entry any time the
+server happens to send us a new version of the same record anyway
+(e.g. if you request the thread of a post, you get a fresh copy of
+that post).
+
+This doesn't work very well. Statuses are often changed behind our
+back, for many legit reasons. Two examples only:
+
+* if you leave this client running, go to another device, and
+  favourite something from an unrelated client, this client won't
+  notice
+* if the poster of a status edits it, or even deletes it, then we
+  don't notice, and keep it shown, leading to an error later if you
+  try to manipulate it.
+
+Probably what we ought to do is to regard _everything_ cached from the
+server as having a limited lifetime, and after that lifetime, fetch it
+again if needed. This includes all the things that `Client` keeps in
+big `HashSet`s; it _also_ includes the lists of ids we've fetched from
+feeds, because those too can change, because someone completely
+deleted a status or because the user who boosted it on to my home
+timeline changed their mind and unboosted it again.
+
+In particular, if you're actually watching a timeline, we should
+re-fetch it from the server periodically, even in the absence of a
+streaming notification. That way, deleted posts actually vanish, so
+the user isn't tempted to try to reply to them.
+
+(Of course, you can't _wholly_ eliminate race conditions there, if
+someone gets really unlucky with the timing. But you can at least get
+rid of _obviously_ stale data.)
+
+### LDB entries should be robust to deletion
+
+LDB entries are currently a single 'last read' id. But if that id
+happens to get deleted, we'd like our last-read position to still be
+where it _was_, and not reset to 'who knows, go back to the top of the
+file'.
+
+I'm not sure how that should best work. _If_ the server guarantees
+that ids are in some kind of well defined order of their string
+values, then we can replace an `=` with a `<=` and we're good. But are
+we? If not, what's another approach? Go by datestamp? Perhaps retain a
+longer list of things that are read, and hope that they don't _all_
+get deleted?
+
+### Streaming improvements
 
 Currently we have exactly one streaming subthread, handling your home
 timeline and notifications. But it's also possible to stream other