[Zope] Caching on-the-fly resized photos (implemented)
Tue, 30 Oct 2001 22:53:18 +0100
first thanks a lot for your efforts.
I have installed the version. And did run update.py (got a Done)
However I get an error when accessing the settings tab on a photo.
Error value: name 'store' is not defined
Source of /AA/xx/bilder/abhoren.jpg/manage_editSettingsForm with fault:
<th class="form-label" align="right">Store:</th>
<dtml-if "store == 'Image'">
I probably have created that photo trough a product of mine. So may I could
forego necessary settings???
I have two small wishes:
- I believe you are mixing tabs and spaces to indent your code. On windows I
have problems to edit it. I first have to load it into Wing and have it
reformatted. It would be nice if you could make your editor to use spaces
- please put the update.py in Photo.Extensions. Its easier to use (must not
----- Original Message -----
From: "Ron Bickers" <firstname.lastname@example.org>
To: "Robert Rottermann" <email@example.com>; "marc lindahl" <firstname.lastname@example.org>
Cc: "Zope listserv" <email@example.com>
Sent: Tuesday, October 30, 2001 9:54 PM
Subject: RE: [Zope] Caching on-the-fly resized photos (implemented)
> > -----Original Message-----
> > From: firstname.lastname@example.org [mailto:email@example.com]On Behalf Of
> > Robert Rottermann
> > I have no displays created automatically. However the user can
> > define a size
> > of the picture she wants to use. From this I then create a display.
> > Since the user will check here "story" while working on it the
> > displays are
> > created at a very early state in the game where waiting is tolerable.
> > The idea of timing out displays is appealing.
> Ok. I've implemented something that seems like a good idea, but I'm not
> sure how it will fly in production. Also, I don't think it directly
> addresses the above scenario. I could probably extend what I have done to
> create displays (not just the images of predefined displays, but actual
> display sizes) when a custom size is requested. I could then tag it such
> that when it times out the entire display (not just the stored image) is
> removed. Robert, would that cover what you're looking for? Read on and
> should make more sense...
> The current CVS at sf.net/projects/zopephoto has options for on-the-fly
> generation of predefined display sizes and a timeout (in minutes)
> with each Photo. Each of these settings can be set in a Photo Folder to
> control the settings in all contained Photos.
> If the "pregenerate" option is chosen and timeout is set to zero, Photos
> behave exactly has they have to date; all displays are generated when the
> Photo is added/updated and the are never purged. If the pregenerate
> is not chosen, displays will be generated on-the-fly as they are
> The timeout is the tricky part. Ideally, every time a display is
> an *access* time of that object would be updated and thus the age of the
> display would be reset to 0. This way, commonly accessed display sizes
> would never be purged. Since ZODB doesn't keep an access time, I could
> use the mod time and update it when the display is requested. The problem
> with this is that it would cause a large number of writes to the ZODB, and
> since ZODB is append only, it would quickly bloat.
> Since I couldn't come up with a better way to track access time, I
> compromised. Every time a display is requested, the age is compared with
> the timeout. If the age is more than half the timeout, the display's mod
> time is reset to zero and any other display sizes whose age is greater
> timeout are purged. With regular ZODB packs (which I assume most people
> anyway), and high timeouts (like several days), this might actually work
> In addition, you can run manage_purgeDisplays() or manage_cleanDisplays()
> which purges all displays (regardless of age) and purges all expired
> displays, respectively. Running these on the Photo Folder will process
> contained Photos. There is a button in the management interface for each
> I can see there might be the desire to have certain displays never expire
> (such as a thumbnail), but instead of adding extra features for that, I'll
> assume for now that in practice, thumbnails would be viewed often enough
> not be purged anyway. We'll see.
> Also, manage_purgeDisplays() and manage_cleanDisplays() each take an
> 'exclude' parameter that is a tuple of displays to *not* purge/clean. In
> each case, excluded displays will have their age reset to zero. From the
> management interface, if you "check" a display(s) and then purge/clean,
> those displays will be excluded. This might seem backwards, but I think
> it's more practical.
> If you're going to try this out, remember to run the upgrade External
> as outlined in UPGRADE.txt. Any and all feedback and suggestions would be
> greatly appreciated.
> Ron Bickers
> Logic Etc, Inc.
> Zope maillist - Zope@zope.org
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-dev )