From 57c515a884594ff492cad63dec57f36942ab41ce Mon Sep 17 00:00:00 2001 From: Simon Tatham Date: Mon, 15 Jan 2024 19:35:13 +0000 Subject: [PATCH] More TODO updates. --- TODO.md | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 54 insertions(+), 1 deletion(-) diff --git a/TODO.md b/TODO.md index afb3952..c3ab91e 100644 --- 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 -- 2.30.2