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 <[EMAIL PROTECTED]>
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
