search

hyphacoop / link.hypha.coop

1 stars 1 forks source link

cache support #4

Closed YurkoWasHere closed 2 years ago

YurkoWasHere commented 4 years ago

Pros over cronjob

Cons over cronjob

Submitted for discussion

benhylau commented 4 years ago

I agree with this approach. The install is easier and would even suggest we make URLToCSV an env var / config in the future to keep the script generic. Cache interval can also be a config if we take that approach. But this seems good for now.

benhylau commented 4 years ago

@ASoTNetworks is this PR still relevant?

benhylau commented 4 years ago

This is a proposal of a caching feature that hasn't been put in use yet. Currently the page is fetched each time.

patcon commented 3 years ago

Thanks Yurko!

gentle -1 on caching without a [future] option to work-around via force refresh, without waiting 15 min.

(I support simplification of deploy; didn't realize this used cron.)

Note that Github already caches, so this would add a 2nd layer of things to flush/circumvent for immediately using a new shortlink. I feel a one-two punch of create-then-use is quite a common use-case -- I def do that before sharing a new shortlink. I would almost prefer opposite feature, of cache-busting options to get around GitHub's raw file cache :)

Ideal scenario I'd love to support:

  1. the ability to either:
    • create new shortlink, or
    • edit existing (!) shortlink,
  2. confirm it works asap through visiting it (currently requires arcane GitHub cachebust, I think, by appending ?v=123 to raw url), and
  3. have assurance that everyone I send link to will have the same experience (no stale local cache that I can't force clean on their behalf)

Thanks for hearing me out! I trust whatever you decide

YurkoWasHere commented 3 years ago

added ?force= to force re-download of cache.

YurkoWasHere commented 3 years ago
dcwalk commented 2 years ago

@YurkoWasHere can you update on status of this PR?