Re: [Zope-dev] CoreSessionTracking stuff
> A session data object timeout of "0" as set in the session data container > means "give me completely persistent session data objects, do not expire > them". Set it to this, and set a high cookie timeout. But yes, a better > way to do something like this is to use sessioning in combination with a > membership product. Ah ok, yes the more I thought about it, the more I thought a Membership system is the way to go. > Local filesystem access won't work across ZEO clients. The primary purpose > of an external data container is to provide access to a shared namespace > between ZEO clients. This doesn't mean someone couldn't write an alternate > data container implementation that uses the filesystem, however. True. But its another option that is quick and easy for many people. I'll put it on my interesting things to do on a rainy day list somewhere > As far as the difficulty of mounting goes, when I can find some time, I want > to write a mounting howto. Thats always welcome. Thanks. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking stuff
Hi Andy, > -Why does an ESDC have a session timeout in 20 minutes, yet the cookie > lifespan can be 30 days. Surely there will be no way to tie a cookie back up > to a session since the ESDC will be have had that person nuked, I was sort > of hoping I coudl persist the data in the ESDC for a long time to provide > storage (I could always set the minutes to 9 or something silly). I > guess if I really want data to be persisted for ever some sort of Membership > product will be needed... A session data object timeout of "0" as set in the session data container means "give me completely persistent session data objects, do not expire them". Set it to this, and set a high cookie timeout. But yes, a better way to do something like this is to use sessioning in combination with a membership product. > -Mounting a non-undoable db into Zope is not trivial unless there is > something Im missing. There's a non-undoable system every Zope installation > has called the file system, why dont we use that? I was thinking we could > modifiy LocalFS to provide that sort of functionality would be much > easier... Local filesystem access won't work across ZEO clients. The primary purpose of an external data container is to provide access to a shared namespace between ZEO clients. This doesn't mean someone couldn't write an alternate data container implementation that uses the filesystem, however. As far as the difficulty of mounting goes, when I can find some time, I want to write a mounting howto. HTH, - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] CoreSessionTracking stuff
More questions on CoreSessionTracking. On on site I wish to persist the information on a session indefinitely so a user can reconnect with those previous session settings. I looked at "External Session Data Container" (ESDC) and had some questions here I go: -Why does an ESDC have a session timeout in 20 minutes, yet the cookie lifespan can be 30 days. Surely there will be no way to tie a cookie back up to a session since the ESDC will be have had that person nuked, I was sort of hoping I coudl persist the data in the ESDC for a long time to provide storage (I could always set the minutes to 9 or something silly). I guess if I really want data to be persisted for ever some sort of Membership product will be needed... -Mounting a non-undoable db into Zope is not trivial unless there is something Im missing. There's a non-undoable system every Zope installation has called the file system, why dont we use that? I was thinking we could modifiy LocalFS to provide that sort of functionality would be much easier... Cheers. -- Andy McKay. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )