Open richsalz opened 1 month ago
The cache lifetime for RFC, BCP, STD references is currently set at 86400*7 seconds, i.e., one week. I didn't want to make it much longer because this goes to bib.ietf.org, which is actively being repaired. The reloading should be plenty fast; is it too slow? (I don't know the details how a cache is managed for github CI, though.)
(Most other cache TTLs are KRAMDOWN_REFCACHETTL, which defaults to 3600 s, i.e., 1 h. DOI and IANA is 86400 s, i.e., 1 d.)
It's not the speed, it's the 'nattering' messages. And then I always ask myself "RFCs are immutable, surely the cache could be months". But since there's a reason (bib.ietf.org repairs), I'm gonna close this. Thanks.
You can get some verbosity by setting the KRAMDOWN_PERSISTENT environment variable to "v", i.e.
export KRAMDOWN_PERSISTENT=v
Martin's config.mk seems to set that to "true" by default„so you should be getting the faster persistent http library. I probably have to re-evaluate whether the fallback to the slower library is still needed in 2024.
... and maybe add a "quiet" setting as well.
A way to dial the verbosity back would be appreciated. That would report when something fails, but otherwise keep its internals to itself.
The verbosity is a nice way to get feedback on why the thing is slow, but I find that it usually isn't that big of a deal: fetching takes ages the first time each week, then you only take a hit when you add a new citation.
Is there it possible to refresh the RFC cache less often, or not at all? Is there a flag that I could then pester @martinthomson to add to his tooling?