From: Paul Winkler <pw_lists@slinkp.com> On Fri, Apr 12, 2002 at 06:47:11AM -0700, Terry Hancock wrote:

...

Hi All,

I'm creating an "infinite-set" type product which generates objects on-the-fly based on their URL. In general many more objects are possible than are reasonable to store, yet relatively few would be used at any one time. Hence, a sensible approach is to provide a cache of recently requested objects and serve from the cache whenever feasible.

Interesting and weird idea... I'm having a hard time imagining an application. Why do you need so many objects?

Well, I actually have more than one application, but the simplest is a variable-size image: You want to be able to get at the image at a desired scale, and you may not know what size you want in advance. Furthermore, you may decide in six months you don't like that size, and you don't want to keep it that way, or you may want your users to decide for themselves what size it should be. Consider "avatars" -- usually square, but sizes vary from 50x50 to 100x100 or larger depending on the location. So why not save them at 200x200 or so and then just deliver to order? E.g: http.../myvarimage --> is the original image http.../myvarimage/f32x32 --> is the image scaled to 32x32 pixels It's pretty easy to see that the number of possible URL/images is enormous. Add a few options (preserve aspect fit vertical, preserve aspect fit horizontal, preserve aspect fit within box, fit exact), and it's even larger. Now imagine you have 1000 such images. You can see it would be sort of annoying to resize them all outside of Zope, and port them all back into it, even if you only forsaw changes on the development timescale. Furthermore, who wants to keep track of them all? More complex examples would include images composed of multiple images or dataplots. I probably will have some of those in my application, too, so why not use the same approach for those? Why use a new URL? Because then it will get cached automatically by the browser and any intervening caches. As I said, I do have a working version, and it's very convenient. However, it's badly designed technically -- it uses a single "resized_image" buffer which I now realize is static and so not thread-safe. If you hit it for simultaneous requests of the same image at different sizes (as would happen on a sampler page in my testing configuration, or about 1 zillion times a day in a production environment with real users), Zope logs a "write conflict" error, the hard drive starts thrashing and Zope never recovers. Eventually the server would crash, I think. Or Zope would. I usually restart Zope first. I definitely need a better implementation! :-(

So, I'm wondering if (via Zope's API, as this is a Python-based

...

product), there's a way to mark an object as not undoable -- i.e. when it gets deleted, it's really gone.

Well, if your objects don't inherit from something which is persistent, they won't get stored in the ZODB at all, AFAIK. They'll simply exist in memory until deleted or until zope restarts, whichever comes first.

Hmm. I only really expect them to last a few minutes, the question is just whether Zope will be able to find them at all. (Also how to avoid using persistent! -- I assume ObjectManager does, I guess it would mean rewriting a lot of code as I don't think there's such a thing as anti-inheriting (keyword "disown"? there's a suggestion for the next version of Python! :D )

But I haven't really looked into it closely.

Well, maybe I can make it work. Thanks for the idea. Terry -- ------------------------------------------------------ Terry Hancock hancock@anansispaceworks.com Anansi Spaceworks http://www.anansispaceworks.com P.O. Box 60583 Pasadena, CA 91116-6583 ------------------------------------------------------