[Seaside] Memory leak?

[Stephen Pair]

After several weeks of developing and testing in a Seaside image, the
image has grown to ~66MB when saved.  Upon further inspection, it
appears that there 4758 instances of WAResponse in my image.  When you
consider the various strings and streams that a WARequest holds, I think
this is accounting for the bulk of my image bloat.

Any ideas whether this is a legitimate issue, or is there something I
should be doing to clean these up?

Also, related to this topic, here are a couple of feature requests:

1) The ability to disable web browser backtracking...if disabled and a
user hits the back button a couple of times, then hits a link...seaside
could inform the user that the link is expired and that they are being
redirected to a current view of their session (I prefer this to
redirecting to a new session because that would make it too easy for a
user to accidentally dump their session and lose anything they were
working on).

2) The ability to restrict the backtacking depth (to conserve server
resources)...this would allow you to make compromise between usability
and server resource consumption...for example, if the backtracking depth
is 10, then the user could back up up to 10 pages and use a link on
those pages

3) Actually, this is more of a question...how closely is Seaside
modeling browser behavior wrt to back tracking?  For example, if a user
backs up one page, then uses a link on that page, Seaside could discard
the orginal page since there is no way of getting back to that page
using the browser's back or forward buttons (granted, you could copy and
paste the URL, but I think it would be quite reasonable if that page and
any links on it were expired).

4) The ability to discard all backtracking information for a given
session.  This may be simple to accomplish and already implemented...if
so, could someone describe the proper way to do this?  There are
circumstances (especially relating to security) where you don't want
someone to be able to backtrack and use old links...the best example is
when a user logs out.  I suppose could trash the session and begin a new
one, but I like have the session map to a web browser/server
interaction, not to a particular authorization context.

Seaside is really great guys!

- Stephen

P.S.  Implementing security on top of Seaside has been a dream!  Seaside
basically has a built in capability framework.  Consider that when you
hit a seaside component, the only thing a user can do is use the links
that have been exposed to him/her on that page.  These are the "keys" to
the capabilities you've granted your user.  All you need to add to the
equation is a framework (like ACLs) to guard Seaside's keys.