[Web-SIG] Session interface

[Mike Orr]

Mike Orr wrote:

>Regarding sessionless persistence, that reminds me of a disagreement I 
>had with Titus in designing session2.  Quixote provides Session.user 
>default None, but doesn't define what other values it can have.  I put a 
>full-fledged User object with username/group/permission info.  Titus 
>puts a string name and stores everything else in his application 
>database.  So his *SessionStore classes put the name in a VARCHAR column 
>and didn't save the rest of the session data.  I argued that "most 
>people will have a User object, and they'll expect the entire Session to 
>be pickled because that's what PHP/Perl do."  He relented, so the 
>current *SessionStores can be used either way.
>
>Perhaps applications should store all session data directly, keyed by 
>session ID (and perhaps "username"), rather than using pickled 
>Sessions.  That would be a good idea for a parallel project.  I'm not 
>sure how relevant that would be to this API except to share "cookie 
>code".  This API + implementations are required in any case, both 
>because "most users" will not consider Python if it doesn't have "robust 
>session handling", and a common library would allow frameworks to use it 
>rather than reinventing the wheel incompatibly.  This is true regardless 
>of the merits of sessions.
>  
>


Another thing about sessionless persistence.  I find sessions useful for 
storing miscellaneous data that would otherwise be sent to the browser 
and back.  Usually it's not a question of byte size but rather: (A) I 
don't want the user to see the data directly -- it contains more 
information about the application/server structure than I care to 
divulve, and (B) I don't want the user manipulating the data and sending 
back something invalid or in the wrong state -- which I would then have 
to error-check.

I could store the data in my relational database, but then I'd have to 
make a half-dozen tables for:

    .user       : a User instance.
    .search   : the latest search results (list of record IDs), the last 
page
        viewed (positive int), and the criteria to redo the search or
        repopulate the search form (dict).
    .message:  a message to display at the next request.
    ... other stuff ??

So I guess sessions are a lazy way to have object-database features in a 
relational-database application.  At least for data that lasts longer 
than a request but shorter than a session timeout.

-- Mike Orr <mso at oz.net>