From: "Ron Bickers" <rbickers-dated-1004726577.71eff0@logicetc.com>
Can you provide an example application where this might be useful?
What about something where the user can select levels of 'zoom', perhaps out of 10 or 20 possibilities? If there are lots and lots of images on the site, then the probability is that few of them will have all zoom levels used. But it also means that if all the zooms are stored with in ZODB you'll get some nice bloat, or if they're in the external fs, you have a big mess that someone has to back up. So it makes sense to generate them on the fly, and cache them so that popular ones are re-used, cutting down CPU processing.
Also, how would you propose caching on-the-fly photos?
I wish I knew! I'm trying to figure that out, but there's little documentation on the RAM Cache manager or howto's or anything...
As stated in the RAM Cache documentation:
"Although Zope does not prevent you from doing so, it generally does not make sense to associate an image or a file object with a RAM cache manager. It will not cache the image or file data, since the data is already available in RAM. However, another kind of cache manager, an accelerated HTTP cache manager, is available and is suitable for images and file objects."
They're referring to Image, which is of course computation-free. They do suggest that it be used for something with 'expensive' computation, like a database lookup. For many applications, using IM or something for resizing or munging an image would qualify as 'expensive'.
So it seems it wouldn't make sense to use a RAM cache with the generated Photo displays, and the accelerated cache is for setting headers for browsers and proxies, etc. to cache. A RAM cache might be useful for on-the-fly photo caching, but wouldn't that quickly eat up memory? I suppose I could store them just like the other display sizes and associate a timeout with them. I'm not sure if that would be sufficient or not.
I was thinking that you would have one RAM Cache for the site, not one for each image. So you can control the overall amount of memory. And, it does what a cache is supposed to, which is save the most amount of repetitive re-computation of the same thing (that is, the most popular image sizes).
Much of this might depend on the application. Should there be infinite size options for the user such that you could end up caching dozens or hundreds of display sizes for a given photo?
For somethings like a photo album, you have only one re-size, which is the thumbnail. Or maybe two, if you want a view that's 100% screensize or something. But the 'zoom' example above is a useful one for multiple resizing. In any case, cached or stored, will benefit from limiting the user's options. Because, this provides the opportunity for overlap among multiple users, which benefits any type of caching (after all, storing the thumbs is still caching...)