I think the "application state" business has been settled, but I'm still
at looking at session.py and coming up with things to change and/or
throw away.

First, I just wrote this paragraph for the docs (on subclassing
Session):

  [...] the only other thing you need to worry about is to ensure that
  you're not interfering with Quixote's base Session class.  Be sure to
  familiarize yourself with the set of instance attributes it defines
  (use the source, Luke) so you don't step on each other's toes.

Yuck!  Python has a perfectly sensible mechanism to prevent related
classes from stepping on each other's toes: use 'self.__foo' instead of
'self.foo'.  I propose that all instance attributes of Session *except
for* 'id' and 'user' should be made private, ie. renamed as follows:

  remote_address   -> __remote_address
  creation_time    -> __creation_time
  access_time      -> __access_time
  form_tokens      -> __form_tokens

I'll add get_remote_address(), get_creation_time(), and
get_access_time() so you can still get at those values if you need
them.

I'm not sure what to do about form_tokens -- we already have
{create,has,remove}_form_token() methods, which should be enough of an
interface.  However, adding the '__' will break the MXPersistentSession
class used by our web site, which persists session data to a ZODB; one
of its tricks is to redefine form_tokens as a PersistentList instead of
a regular old list.  That won't work if the *_form_token() methods in
Quixote's Session class refer to self.__form_tokens.  One compromise is
to say that subclasses are allowed to muck about with form_tokens, but
outsiders should stay away -- ie. use the informal '_form_tokens'
notation.

Finally, you'll note that the 'actual_user' attribute does not appear on
the above list.  We use this to give MEMS Exchange staff the ability to
impersonate other users of our web site, which is necessary for a
variety of unpleasant reasons.  But I really don't think it belongs in
Quixote's session class -- I think it's a MEMS Exchange-specific thing
that belongs in our custom Session subclass.  Thus, I propose removing
it from Quixote.  If you disagree and think that all Quixote-based web
sites ought to have the equivalent of Unix' real-vs-effective UIDs,
speak up.

Thoughts?

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