On Tue, Sep 14, 1999 at 02:24:21PM -0500, Evan Simpson wrote:
Jason Jones wrote:
From: Peter Sabaini <cccp@oeh.tu-graz.ac.at>
[snip]
On Tue, 14 Sep 1999, Jason Jones wrote:
:As I understand it, this scheme would pretty much create a cached copy of :the rendered object which would itself live in the ZODB.
Not in the ZODB -- in memory. The ZCache object would, of course, live in the ZODB and be demand loaded and unloaded like any other object. The actual cached text would be stored in a transient variable, and would evaporate if the ZCache object were unloaded. This is good, since Zope will only unload it if it's taking up space that more popular objects need (unless rendering the object is **very** expensive; what then?).
Then you fall back to the case we have now: the developer does 'ad hoc' caching, like the XML->DTML render someone else mentioned. If generating the rendered version is **very** expensive, it should live in it's own object in the ZODB. The developer can make her own 'rerender this object' method. I think it falls into the same class as caching at page boundries: nice but not compelling. Personally, I can't think of an example of an object that would be _that_ expensive to render: What sort of thing are you envisioning in that catagory, that wouldn't already be represented as it's own object? Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005