Chris Rogers just found this from google: see the http header 'cache-control'

The server response should set the Cache-control HTTP header to "no-store"
Here it is explained how to do it with django:
https://docs.djangoproject.com/en/dev/topics/cache/#controlling-cache-using-other-headers
I suggest you use the never_cache decorator.

About the refresh, HTML5 Server-Side Events are good way to refresh when new data is available.

The caching isn't the browser or Django. Just now, it's the implementation. It reads a directory of EPS, creates PNG thumbnails and stores these. If the page is reloaded it only creates new thumbnails for which there haven't been any already created. This was to avoid a refresh of a page with many images grinding to a halt as it attempted to regenerate all the thumbnails.

I've checked in a new version (11) that:

• Regenerates the thumbnails every time the index page is reloaded.
• Adds the following to the HTML to give a browser refresh every 5s (tested on IE, Firefox and Safari):
  

  <meta http-equiv="REFRESH" content="5">
  

Wonderful, we'll test it out right now. Quick question: how many thumbnails per second can be reasonably generated? The implementation mentioned above works for the moment... just don't want an accidental DOS attack.

RIght now everything is in local 127.0.0.1 mode.

Sorry, I'm not sure what "reasonable" might be. I implemented it the way I did originally in case it might be 100s.

Is it computationally expensive? Should we cache it rather? Well, in the long term I guess the answer is 'yes' since, as you said correctly, 100 or so plots.

Again, don't know. I ass-umed it would be (EPS->PNG) but I was focusing more on getting "something" working than any performance assessments (since we'd be returning to this component later)