I'm still trying to reduce the amount of documentation to write by
removing code.  ;-) My current target is the pointless abstraction
called "application state", which I thought was a good idea when I first
wrote the code that ultimately evolved into Quixote's session.py.

The idea was as follows: complex web sites (like ours) would only have
one session object per user/host/browser, but they might have lots of
session information to carry around.  It seemed like a good idea to
partition that session information into multiple objects, which made me
think that a formal registry mapping "application names" to "application
state" objects in every Session object was a good idea.

As it turns out, this is all quite unnecessary, and we make only cursory
use of it on our site.  (Looks like we have precisely two "application
state" classes -- all the rest of our site manages to get away without
storing anything in the session object.)

In retrospect, my major error was premature generalization based on the
assumption that throwing stuff into the session structure is always a
good and useful thing.  It turns out that deciding what info to put in
the session is quite tricky -- the user can *always* bite you with that
pesky "back" button.

So, would anyone object if I threw out all the cruft in session.py
relating to "application state"?  Is anyone apart from us using it?

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org