Update the database *after* printing
metov opened this issue · 3 comments
The tldr client frequently wants to update pages, which requires a network request, which takes a few seconds. This seems to me like not ideal UX for a quick reference tool. When I'm trying to look up some basic syntax of a command, giving an answer quickly is more important than giving a definitive one - if I want the definitive, I'd be looking at the man page or searching on the internet instead of using tldr.
From what I can tell, the current flow is:
- User requests page of topic
- tldr checks cache, maybe updates the page
- tldr shows the page
I think a better UX would be:
- User requests page of topic
- If page is present in the cache:
- tldr shows it
- tldr updates the page (if cache is stale)
- If the new version is actually different, tldr prints a message: "This page has been changed from the one you just saw. Run tldr again to see the new version."
- If page is not present in the cache at all:
- tldr prints a message: "Hold on, fetching page from the database..."
- tldr updates the page
- tldr shows it
This is of course more complex, but I think justified by the benefit to the user. What do you think? I'm willing to author a PR if the idea sounds reasonable.
I think an alternative, less invasive solution would be for me to simply create a systemd timer that runs tldr --update_cache every day or so, which would ensure that the cache is never stale.
If this is the recommended solution, though, it would be useful to have a new --update-all argument, which pulls all of the pages rather than what's in the cache. The entire tldr pages repo is currently only 27 MB, so the latency-space tradeoff seems reasonable.
I can see a downside with this, although not a major one by any means.
Recently, I made a commit (tldr-pages/tldr#12983) which fixed a very very bad oversight, which would have completely either ruined someones PC, or just given them a bad time.
If the cache hadn't been updated first, users could have potentially gotten the outdated and damaging page.
This is probably 1 in a million but just putting it out there.
Regarding the systemd timer, that should be opt-in if it were to be done, people don't like their computer contacting things without their knowledge, also 27MB is quite sizeable in terms of internet usage where on cellular devices, most still have data caps and even home internet connections for some people.
@CleanMachine1 Thanks for your response.
If the cache hadn't been updated first, users could have potentially gotten the outdated and damaging page.
I agree with this point. That's why I suggest that if tldr detects the page has been updated, it should print a warning. When the user sees this, it would be up to them to just re-run the same tldr command so they can view the same page again.
In retrospect, maybe some people don't want to see out of date pages at all. So if we just had a --update_after switch or UPDATE_AFTER=1 environment variable, that would also solve my issue without disrupting the users who would rather wait for the update.
Regarding the systemd timer, that should be opt-in if it were to be done
Agreed. Tldr shouldn't automatically install such a timer. People who want the timer, can write it themselves. But if we added an --update-all option, it would become much easier to write such a timer.