Cache busting support

[epage]

This is created from #254.

Options

• site.bust_cache variable that is a timestamp of when the program is run
• asset.<path>.bust_cache variable that is checksum of the asset
  • This must be conditionally enabled to avoid the performance hit for people who don't care

[berkus]

This sounds right, and supporting both options should be done. Some sites would opt for nothing, some for site timestamp, and some with bigger cache pressure might just want the per-asset cache buster.

Probably a config option, cache-bust: with values none, timestamp(default) and checksum?

[epage]

I think both can be implemented with little problem.

The site timestamp is the easiest to get implemented.

An asset checksum might take more work. It can be done now but the performance hit might be a frustration. I can see the idea of having a flag for that. Moe ideally, I think is a refactoring I want to do. The idea is to re-architect inspired by ECS which would effectively make our data an "customized, in-memory database". That combined with some tweaks for Liquid would allow our checksumming to be lazy.

One of the design problems I've been having with asset checksum and general page metadata is how to make it work. If I take "./css/theme.css" and turn it into asset.css.theme.checksum, what if we had a checksum file? How do we make asset / page metadata not conflict with user content?

We might say "just include the extension". So

asset.css.theme.checksum
becomes
asset.css.theme.css.checksum
but what if someone has a theme/css?

Thoughts on a solution

• We could create a scheme for this to always work.
• We could make this not always work and just define what the behavior will be
  • This depends on the type of metadata we provide. What is the probability of a conflict?

[berkus]

could it become something like asset.css.theme$checksum$ ?

[SArpnt]

about the performance hit from an asset checksum, your problem is probably using the wrong hash algorithm. web assets don't need cryptographic hashes. i think the correct hash for this use case would be xxhash16.
whichever hash algorithm that gets used should be documented so that it can be matched with other tools, for example to change urls in javascript to match

also, about the design conflict, i'd expect selecting files to work something like asset.css."theme.css".checksum, and only allow asset.css.theme if there aren't any other files that have the same name but other extension. asset.css.theme.css would never work since theme isn't a folder