4 ms·

Y’know, browsers already have several built-in mechanisms for transparent caching without having to rely on Web Storage. I'd strongly recommend taking a look at

Y’know, browsers already have several built-in mechanisms for transparent caching without having to rely on Web Storage. I'd strongly recommend taking a look at them before implementing a jQuery plugin. The only problem is that HTTP-based caching requires sane server URLs, and the Rails code here indicates a lack of understanding of how to build a cache-friendly URL structure. I'm also a little fazed by the fact that the 'isCacheValid' key not only checks the validity of the cache, but also sets a cache key at the same time.

deleted 14y ago
[deleted]
robinkomiwes 14y ago
I'm one of the guys behind this plugin. In our case built-in browsers cache mechanisms were a no go because we needed to have a programmatic control over our cache. Our app is heavily powered by realtime notifications from the server, and we needed a way to invalidate the cache when some events occurs. About 'isCacheValid' setting the cache key, you're right, it should have been done in the success callback. The gist is going to be updated soon with your feedback.
- untog 14y ago
  Couldn't you use just an extra query string parameter when you want to force a refresh? Like, ?v=12312312353. It's a little hackish I'll grant you, but so is caching HTTP in LocalStorage.
  - d0ugal 14y ago
    This is better.
  - deleted 14y ago
    [deleted]
  - pohl 14y ago
    This won't actually cause anything to be evicted from the cache. It just adds a new cache entry with a new key. This is poor resource management, and removes some of the appeal of going out of your way to reuse the browser's cache mechanism.
    - untog 14y ago
      Sure, but the HTTP cache is managed by the browser. Unless you are pulling down mammoth amounts of data, cache management is unlikely to be a concern for you.
    - d0ugal 14y ago
      Browsers cache many things each time you go to a website - all the html and assets (js/css/images) will be potentially cached (depending on headers). Often you will not go to that website again. They are optimised for this.
silasb 14y ago
Are you referring to using Conditional Get Request for HTTP caching? If so I still think you need to store the results somewhere, after you get the 304 Not Modified response back jQuery will return the blank body of response to the success method. Am I missing something? I recently ran into something like this where I wanted to cache a JSON (maybe it was JSONP), but couldn't find a solution to store the cached JSON somewhere that works for IE.
- eli 14y ago
  If the cache headers are properly configured and you request a page that's cached, the browser will simply serve the page from the cache. It is transparent to the user; it looks just like a normal page request, except the data doesn't actually travel over the wire.
k3n 14y ago
> The only problem is that HTTP-based caching requires sane server URLs This works great insofar as you aren't bound by PCI requirements; per PCI, you cannot transmit potentially sensitive data in a GET request, and so basically every request must be a POST. Furthermore, implementing CSRF via GET is a non-starter -- that's not even an option.

deleted 14y ago

[deleted]

robinkomiwes 14y ago

I'm one of the guys behind this plugin. In our case built-in browsers cache mechanisms were a no go because we needed to have a programmatic control over our cache. Our app is heavily powered by realtime notifications from the server, and we needed a way to invalidate the cache when some events occurs. About 'isCacheValid' setting the cache key, you're right, it should have been done in the success callback. The gist is going to be updated soon with your feedback.

untog 14y ago
Couldn't you use just an extra query string parameter when you want to force a refresh? Like, ?v=12312312353. It's a little hackish I'll grant you, but so is caching HTTP in LocalStorage.
- d0ugal 14y ago
  This is better.
- deleted 14y ago
  [deleted]
- pohl 14y ago
  This won't actually cause anything to be evicted from the cache. It just adds a new cache entry with a new key. This is poor resource management, and removes some of the appeal of going out of your way to reuse the browser's cache mechanism.
  - untog 14y ago
    Sure, but the HTTP cache is managed by the browser. Unless you are pulling down mammoth amounts of data, cache management is unlikely to be a concern for you.
  - d0ugal 14y ago
    Browsers cache many things each time you go to a website - all the html and assets (js/css/images) will be potentially cached (depending on headers). Often you will not go to that website again. They are optimised for this.

silasb 14y ago

Are you referring to using Conditional Get Request for HTTP caching? If so I still think you need to store the results somewhere, after you get the 304 Not Modified response back jQuery will return the blank body of response to the success method. Am I missing something? I recently ran into something like this where I wanted to cache a JSON (maybe it was JSONP), but couldn't find a solution to store the cached JSON somewhere that works for IE.

eli 14y ago
If the cache headers are properly configured and you request a page that's cached, the browser will simply serve the page from the cache. It is transparent to the user; it looks just like a normal page request, except the data doesn't actually travel over the wire.

k3n 14y ago

> The only problem is that HTTP-based caching requires sane server URLs This works great insofar as you aren't bound by PCI requirements; per PCI, you cannot transmit potentially sensitive data in a GET request, and so basically every request must be a POST. Furthermore, implementing CSRF via GET is a non-starter -- that's not even an option.