cabo / kramdown-rfc

An XML2RFC (RFC799x) backend for Thomas Leitner's kramdown markdown parser
MIT License
195 stars 83 forks source link

Control verbosity of reference cache refresh #243

Open richsalz opened 1 month ago

richsalz commented 1 month ago

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?

cabo commented 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.)

richsalz commented 1 month ago

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.

cabo commented 1 month ago

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.

cabo commented 1 month ago

... and maybe add a "quiet" setting as well.

martinthomson commented 1 month ago

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.