Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update the database *after* printing #197

Open
metov opened this issue Jun 24, 2022 · 3 comments
Open

Update the database *after* printing #197

metov opened this issue Jun 24, 2022 · 3 comments

Comments

@metov
Copy link

metov commented Jun 24, 2022

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:

  1. User requests page of topic
  2. tldr checks cache, maybe updates the page
  3. tldr shows the page

I think a better UX would be:

  1. User requests page of topic
  2. If page is present in the cache:
    1. tldr shows it
    2. tldr updates the page (if cache is stale)
    3. 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."
  3. If page is not present in the cache at all:
    1. tldr prints a message: "Hold on, fetching page from the database..."
    2. tldr updates the page
    3. 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.

@metov
Copy link
Author

metov commented Jun 24, 2022

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.

@CleanMachine1
Copy link
Member

CleanMachine1 commented Jul 4, 2024

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.

@metov
Copy link
Author

metov commented Oct 18, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants