On Tue, 01 Aug 2006 19:49:41 +0200, Manlio Perillo email@example.com 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.