17 ms·

I think that the terminology you use is very different from the standard one. > If you can't dispose of a "cache" without a thought beyond "Gosh, my app's perf

by Peaker 15y ago

I think that the terminology you use is very different from the standard one. > If you can't dispose of a "cache" without a thought beyond "Gosh, my app's performance is going to suffer until this cache is repopulated" According to what you're saying: "Write cache" or "dirty cache" are oxymorons, and yet these terms are used everywhere.

jerf 15y ago
You didn't finish my quote, and the the part you cut off is not incidental: "you are asking for pain". Many things at hardware level are indeed asking for pain. That smart people have labored at length to make them work anyhow doesn't mean it wasn't quite painful. I didn't say it was impossible. For hardware, it can be a sensible tradeoff. For a generalized web application installation method I don't think it is; it writes into the standard that you must know a lot of very subtle things that your average programmer doesn't even see as issues. This is a bad thing to put into a standard. Better to do something stupider-but-easier, and let people get clever if they think they have some compelling need. Though stepping one "why" back, the real problem here is that the W3C shouldn't be trying to prospectively write a standard this complicated at all. Why they keep doing that and why people care when they do is beyond me, their track record for creating standards de novo is terrible. This really does call for a few browsers to just try some stuff and see what sticks, no matter how "proprietary" it may make the solution, because no group of people is smart enough to solve all the problems that arise here without even a quarter of an implementation in hand somewhere.
- Peaker 15y ago
  Not just hardware. Kernel file systems and block devices have write caches. Storage systems have write caching. It is a pretty important mechanism, and may or may not be painful depending on reliability requirements.

by Peaker 15y ago

jerf 15y ago

You didn't finish my quote, and the the part you cut off is not incidental: "you are asking for pain". Many things at hardware level are indeed asking for pain. That smart people have labored at length to make them work anyhow doesn't mean it wasn't quite painful. I didn't say it was impossible. For hardware, it can be a sensible tradeoff. For a generalized web application installation method I don't think it is; it writes into the standard that you must know a lot of very subtle things that your average programmer doesn't even see as issues. This is a bad thing to put into a standard. Better to do something stupider-but-easier, and let people get clever if they think they have some compelling need. Though stepping one "why" back, the real problem here is that the W3C shouldn't be trying to prospectively write a standard this complicated at all. Why they keep doing that and why people care when they do is beyond me, their track record for creating standards de novo is terrible. This really does call for a few browsers to just try some stuff and see what sticks, no matter how "proprietary" it may make the solution, because no group of people is smart enough to solve all the problems that arise here without even a quarter of an implementation in hand somewhere.

Peaker 15y ago
Not just hardware. Kernel file systems and block devices have write caches. Storage systems have write caching. It is a pretty important mechanism, and may or may not be painful depending on reliability requirements.