[Zope] Recursive aquisition: good or bad?

[Tom Schwaller]

Michel Pelletier wrote:

> > /change/change/all/update/search/change
> >
> > (different menu items clicked one after the other).
> > Zope caches all this paths (is that correct?),
> > so after a while Zope was very slow
> 
> Hmm.. this was a performance problem?  I would guess it wouldn't be that
> much of a problem unless your paths got REALLY big.

I just looked at a few lines in the logfile,
but this recursive links where accumulated during a whole 
day, so 20-30 steps until maybe 100 are the region we talk 
about here. Since I corrected the bug, the server runs normally
(the few other unusual requests do not disturb it anymore..)

> > At least things like
> >
> > /Documentation/Documentation/Documentation/Documentation
> 
> You can't forbid people, no, but you can prevent such paths from being
> constructed from *your* code.  I don't think there is any kind of Denial

that's what I tried, :-) but nevertheless I still detected that
kind of weird requests 

> of Server attack possible from this, a mild annoyance at best.

Anobody here to try that with a small script? Death by recursion :-)

> > should not be allowed or did I miss some Zope Zen?
> 
> I think it should be allowed, and that the Zen be elaborated on a bit.
> You shouldn't design your site so that these things occur unless you
> really want it.

As far as I can see I did exactly that (exept for some internal stuff,
where I did a mistake which generated my problems..)

Ty Sarna wrote:
> In the sites I'm managing, the "modes" are some cases different modes
> (like "show me this as text", "show me this as html", "provide the
> ability to edit the data", which can possibly be combined, like html
> view with editing).  In other cases the modes are actually different
> access levels.  app may reference a DTML method "menu" in several
> places. app can contain a basic definition of menu with the basic
> choices and Anonymous view permission.  You might have a "mode" folder
> called "author" which contains a method of the same name but with higher
> security restructions and that provide more choices.  by accessing
> app/author/...  instead of app/..., the user is forced to authenticate
> and will be given more menu choices.

yes, that's really cool and I had this kind o things 
in my mind too (frame-version, noframe-version as a 
simple example. You detailed much more exciting stuff 
which would certainly be interesting to look at ;-)

I just got a strange feeling when the server was knocked 
down last week with this "side-effect", but you both persuaded 
me: it's a feature :-)

cu and thanks for the insight

-- 

Tom 
http://www.linux-magazin.de/