4 ms·

You can eliminate the cache invalidation problem by not reusing old names for new things.

by ruuda 4y ago

onion2k 4y ago
That doesn't solve cache invalidation; that just means you're always invalidating the cache even in cases where you don't actually want to.
- rightbyte 4y ago
  You just solve that by using another level of indirection. Duh.
- ithkuil 4y ago
  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.
jonatron 4y ago
newester_new_final_v4_new.txt
- deleted 4y ago
  [deleted]
rightbyte 4y ago
Doesn't that just move the problems to more "naming things" though?
- ithkuil 4y ago
  Yes, naming things is intimately tied to cache invalidation. That's why the two things are together in that maxim. Not sure why people think it has to so with naming variables or functions...
  - codetrotter 4y ago
    > Not sure why people think it has to so with naming variables or functions... I think it’s open to interpretation. And I think it is valid to apply the saying to naming of variables, functions, and many other things. See https://skeptics.stackexchange.com/questions/19836/has-phil-karlton-ever-said-there-are-only-two-hard-things-in-computer-science https://skeptics.stackexchange.com/questions/19836/has-phil-... Links to https://www.karlton.org/2017/12/naming-things-hard/ https://www.karlton.org/2017/12/naming-things-hard/ Links to a bunch of places. None of the ones I looked at seem to confidently say what was originally meant by the saying. Either way, regardless of what the guy meant when he originally used to say it, it’s allowed to apply a saying to new situations.
  - CommitSyn 4y ago
    > That's why the two things are together in that maxim. I think you missed the joke.
    - onlypositive 4y ago
      Did they?
      - ithkuil 4y ago
        I _think_ it became a joke, accidentally.
      - CommitSyn 4y ago
throwanem 4y ago
Not using old names for new things in this case means abandoning the concept of Git branch tags.
endymi0n 4y ago
Sounds a little bit like the standard recipe of any functional programming enthusiast: Just use pure functions! Except that they‘re colliding all the time with that tiny problem that the world isn‘t pure... People expect the same page at the same URL, with different content, tomorrow, so good luck choosing a different one than the one they have bookmarked and that ranks on Google. Caching doesn‘t get any less hard by trying to define the problem away.
deleted 4y ago
[deleted]

You can eliminate the cache invalidation problem by not reusing old names for new things.

by ruuda 4y ago

You can eliminate the cache invalidation problem by not reusing old names for new things.

That doesn't solve cache invalidation; that just means you're always invalidating the cache even in cases where you don't actually want to.

rightbyte 4y ago
You just solve that by using another level of indirection. Duh.
ithkuil 4y ago
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.

jonatron 4y ago

newester_new_final_v4_new.txt

deleted 4y ago
[deleted]

rightbyte 4y ago

Doesn't that just move the problems to more "naming things" though?

ithkuil 4y ago
Yes, naming things is intimately tied to cache invalidation. That's why the two things are together in that maxim. Not sure why people think it has to so with naming variables or functions...
- codetrotter 4y ago
  > Not sure why people think it has to so with naming variables or functions... I think it’s open to interpretation. And I think it is valid to apply the saying to naming of variables, functions, and many other things. See https://skeptics.stackexchange.com/questions/19836/has-phil-karlton-ever-said-there-are-only-two-hard-things-in-computer-science https://skeptics.stackexchange.com/questions/19836/has-phil-... Links to https://www.karlton.org/2017/12/naming-things-hard/ https://www.karlton.org/2017/12/naming-things-hard/ Links to a bunch of places. None of the ones I looked at seem to confidently say what was originally meant by the saying. Either way, regardless of what the guy meant when he originally used to say it, it’s allowed to apply a saying to new situations.
- CommitSyn 4y ago
  > That's why the two things are together in that maxim. I think you missed the joke.
  - onlypositive 4y ago
    Did they?
    - ithkuil 4y ago
      I _think_ it became a joke, accidentally.
    - CommitSyn 4y ago

throwanem 4y ago

Not using old names for new things in this case means abandoning the concept of Git branch tags.

endymi0n 4y ago

Sounds a little bit like the standard recipe of any functional programming enthusiast: Just use pure functions! Except that they‘re colliding all the time with that tiny problem that the world isn‘t pure... People expect the same page at the same URL, with different content, tomorrow, so good luck choosing a different one than the one they have bookmarked and that ranks on Google. Caching doesn‘t get any less hard by trying to define the problem away.

deleted 4y ago

[deleted]