4 ms·

Content addressing causes the name to change only when the content changes, which also means the name doesn't change if the content doesn't change, this by defi

Content addressing causes the name to change only when the content changes, which also means the name doesn't change if the content doesn't change, this by definition you don't have spurious cache invalidations

jakear 4y ago
And how do you check what the new name of the content you haven't seen is?
- taeric 4y ago
  Serious question? There will be a root object that has a stable name through updates. When you write that, you embed current content hashes in it. Someone could get the cached of it, of course. But since it content addresses what it links to, it should avoid incoherent groups of cached data.
  - jakear 4y ago
    I agree this would provide for increased coherency, but the additional indirection is hardly ideal. And really it's just kicking the caching problem up to a super-object that will probably be thrashed much harder than any individual file, and may be larger than each individual file. All in all it's a "certified hard problem", there's a bunch of domain specific nuance an HN thread couldn't hope to capture.
    - taeric 4y ago
      The extra indirection may or may not be a problem, of course. For a lot of places this is used, it is "index.html," after all. That said, I do find folks bend way too many things into fitting this pattern; such that I do not mean to be dismissive of the criticism.
ilyt 4y ago
But where client gets the new name it should download for? As long as name client asks for (even if it is reference) is constant, it can have cache problems. Of course it makes it simpler as youc an opt to cache it so short that invalidation is less of an issue, but that's again working around cache invalidation
onion2k 4y ago
There are many problems with that though. For example, if your CSS changes you change the filename... but now you need to change the HTML file that references it. You can't change that easily. Or what if your CSS change just deletes some unused classes... it'd be fine for users to keep the old version until it expires. If you rename the resource you'll be causing a lot of users to wait unnecessarily. Not a huge problem, unless you're Meta or Google. And so on. When people say cache invalidation is hard it's best to believe them, because it is.

jakear 4y ago

And how do you check what the new name of the content you haven't seen is?

taeric 4y ago
Serious question? There will be a root object that has a stable name through updates. When you write that, you embed current content hashes in it. Someone could get the cached of it, of course. But since it content addresses what it links to, it should avoid incoherent groups of cached data.
- jakear 4y ago
  I agree this would provide for increased coherency, but the additional indirection is hardly ideal. And really it's just kicking the caching problem up to a super-object that will probably be thrashed much harder than any individual file, and may be larger than each individual file. All in all it's a "certified hard problem", there's a bunch of domain specific nuance an HN thread couldn't hope to capture.
  - taeric 4y ago
    The extra indirection may or may not be a problem, of course. For a lot of places this is used, it is "index.html," after all. That said, I do find folks bend way too many things into fitting this pattern; such that I do not mean to be dismissive of the criticism.

ilyt 4y ago

But where client gets the new name it should download for? As long as name client asks for (even if it is reference) is constant, it can have cache problems. Of course it makes it simpler as youc an opt to cache it so short that invalidation is less of an issue, but that's again working around cache invalidation

onion2k 4y ago

There are many problems with that though. For example, if your CSS changes you change the filename... but now you need to change the HTML file that references it. You can't change that easily. Or what if your CSS change just deletes some unused classes... it'd be fine for users to keep the old version until it expires. If you rename the resource you'll be causing a lot of users to wait unnecessarily. Not a huge problem, unless you're Meta or Google. And so on. When people say cache invalidation is hard it's best to believe them, because it is.