On Tue, 01 Aug 2006 19:49:41 +0200, Manlio Perillo <[EMAIL PROTECTED]> wrote:
Ok, but you can store the session in a global dictionary (as done in
your default implementation).
The sessions are available, at least if the server is not rebooted.
I think that a database should be used only if you want to share
sessions beetwen distributed servers (or if you are using a server like
Apache).
This is just wrong. Persistent sessions are useful exactly to avoid re-creating
them when rebooting the application.
No, I meant storing data that shoud be stored for the "lifetime of the
rendering".
As done in formal with the forms data and errors.
Where should be this data stored?
It shouldn't. Pass it through the callee.
The request object is not good?
Not in its current shape and most probably not at all.
So sessionwrapper parameter is not needed?
The guard attribute is on the Session not on the SessionManager and it's a
detail that is not exposed because it's just to make it handier for the user to
run the 3 lines in the docstring.
Yes, but guard requires a lot of "things" to happen for every request.
I would like to do some benchmark, but if I only need to know the
authenticated username, maybe I have no need for a session wrapper (but
I need the session manager).
You might just avoid using cred/guard entirely and write your own thing if you
like... guard is not meant to work without cred yet you were proposing to rely
on the avatarId which is an internal cred thing.
Anyway I'd be curious to know how you are going to implement cred integration
without a SessionWrapper like resource with the current interface.
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
