[Zope] Object without Undo?

[Terry Hancock]

> 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
------------------------------------------------------