Valentino Volonghi aka Dialtone ha scritto:
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.
And what's the problem? Hopefully you are not going to reboot the server every week, and users can always relogin.
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.
Ok, but this means that *every* current application should be rewritten...
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
Ok, but you pass a session to the loggedIn method. So you can do (if I'm not wrong):
def loggedIn(self, session, request):
if request.args.get('rememberMe'): session.guard.makePersistentCookie(session, request, max_age=self.sessionPersistentLifetime) self.makePersistentSession(session)
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.
confusing avatarID was a my error...
Anyway I'd be curious to know how you are going to implement cred integration without a SessionWrapper like resource with the current interface.
Of course there will be no cred integration ;-).
I don't want (still) to use guard because there are a lot of things that I do not understand.
Like support for multiple portals, setResourceForPortal and so.
Every time I think I'm beginning to understand, it suffice to read some code (as Weever or Stiq) for understanding that I do not understand ;-).
Thanks and regards Manlio Perillo