Hi
there,
there is any kind of good practice
to use session in production?
like an average duration that can be
recomended?
I saw that in basecamp one can
be logged and hours later add some record and it reponds fine. Can that behavior
be implemented with seaside apps? if so, what approaches to implement that one
can use?
thanks,
_______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
2007/9/4, Sebastian Sastre <[hidden email]>:
> > > Hi there, > > there is any kind of good practice to use session in production? > > like an average duration that can be recomended? > > I saw that in basecamp one can be logged and hours later add some record > and it reponds fine. Can that behavior be implemented with seaside apps? On "normal" Smalltalk systems the limit to that is the limit of your image size. There are Smalltak systems with an image limit of 8192 terabytes ;). Cheers Philippe > if > so, what approaches to implement that one can use? > > thanks, > > > > Sebastian > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Sebastian Sastre-2
I would say typical length of your session depends on the pattern of use
combined with security considerations. Former is very easy to determine if you use Google Analytics (see "Avg. Time on Site") or similar web metrics product. Say, if users typically spend ~5 minutes on your site anyway, a timeout of 10 minutes should not be disruptive to anyone. Latter is an arbitrary value that you are comfortable with (or have regulations to comply with), for instance web banking applications try to keep it to a minimum to minimize risks associated with users leaving their browsers open. -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Sebastian Sastre > Sent: Tuesday, September 04, 2007 6:22 AM > To: 'Seaside - general discussion' > Subject: [Seaside] Seaside sessions > > Hi there, > > there is any kind of good practice to use session in production? > > like an average duration that can be recomended? > > I saw that in basecamp one can be logged and hours later add some > record and it reponds fine. Can that behavior be implemented with > apps? if so, what approaches to implement that one can use? > > thanks, > > Sebastian > > _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Thanks Boris. I'm seeing that Google Analytics is a must for that and other
business things. I'll see how to integrate it to the app. Sebastian Sastre > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Boris Popov > Enviado el: Martes, 04 de Septiembre de 2007 11:09 > Para: Seaside - general discussion > Asunto: RE: [Seaside] Seaside sessions > > I would say typical length of your session depends on the > pattern of use combined with security considerations. Former > is very easy to determine if you use Google Analytics (see > "Avg. Time on Site") or similar web metrics product. Say, if > users typically spend ~5 minutes on your site anyway, a > timeout of 10 minutes should not be disruptive to anyone. > Latter is an arbitrary value that you are comfortable with > (or have regulations to comply with), for instance web > banking applications try to keep it to a minimum to minimize > risks associated with users leaving their browsers open. > > -Boris > > -- > +1.604.689.0322 > DeepCove Labs Ltd. > 4th floor 595 Howe Street > Vancouver, Canada V6C 2T5 > http://tinyurl.com/r7uw4 > > [hidden email] > > CONFIDENTIALITY NOTICE > > This email is intended only for the persons named in the > message header. Unless otherwise indicated, it contains > information that is private and confidential. If you have > received it in error, please notify the sender and delete the > entire message including any attachments. > > Thank you. > > > -----Original Message----- > > From: [hidden email] [mailto:seaside- > > [hidden email]] On Behalf Of Sebastian Sastre > > Sent: Tuesday, September 04, 2007 6:22 AM > > To: 'Seaside - general discussion' > > Subject: [Seaside] Seaside sessions > > > > Hi there, > > > > there is any kind of good practice to use session in production? > > > > like an average duration that can be recomended? > > > > I saw that in basecamp one can be logged and hours > later add some > > record and it reponds fine. Can that behavior be implemented with > seaside > > apps? if so, what approaches to implement that one can use? > > > > thanks, > > > > Sebastian > > > > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Sebastian Sastre-2
> -----Original Message-----
> From: [hidden email] > [mailto:[hidden email]] On Behalf > Of Sebastian Sastre > Sent: Tuesday, September 04, 2007 6:22 AM > To: 'Seaside - general discussion' > Subject: [Seaside] Seaside sessions > > Hi there, > > there is any kind of good practice to use session in production? > > like an average duration that can be recomended? > > I saw that in basecamp one can be logged and hours later > add some record and it reponds fine. Can that behavior be > implemented with seaside apps? if so, what approaches to > implement that one can use? > > thanks, > > Sebastian I don't like web apps that timeout on me, nor do I like wasting server resources with long session timeouts, so I keep the 10 minute timeout and the root component of my apps create a single perodical that does nothing that fires just short of the session timeout to touch the server every so often. This ensures any browser that is actually open won't timeout and any actual unused sessions expires shortly. Ramon Leon http://onsmalltalk.com _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
>> -----Original Message-----
>> Sebastian Sastre [snip] Ramon Leon wrote: > I don't like web apps that timeout on me, nor do I like wasting server > resources with long session timeouts, so I keep the 10 minute timeout and > the root component of my apps create a single perodical that does nothing > that fires just short of the session timeout to touch the server every so > often. This ensures any browser that is actually open won't timeout and any > actual unused sessions expires shortly. I like that. Would that be a reasonable default for Seaside session behavior? It seems that it would be nice to be in the core unless there are problems I don't see. I definitely agree with Ramon and as an end user would greatly appreciate such a feature. And as a web developer taking good care of resources is also important. This strikes an excellent balance. Jimmie _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
I definitely would not want this as default, but perhaps as decoration
that one could use or a component to include as a child as part of Seaside core? -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Jimmie Houchin > Sent: Tuesday, September 04, 2007 8:18 AM > To: Seaside - general discussion > Subject: Re: [Seaside] Seaside sessions > > >> -----Original Message----- > >> Sebastian Sastre > [snip] > > Ramon Leon wrote: > > I don't like web apps that timeout on me, nor do I like wasting > > resources with long session timeouts, so I keep the 10 minute timeout > and > > the root component of my apps create a single perodical that does > nothing > > that fires just short of the session timeout to touch the server every > so > > often. This ensures any browser that is actually open won't timeout and > any > > actual unused sessions expires shortly. > > I like that. Would that be a reasonable default for Seaside session > behavior? It seems that it would be nice to be in the core unless there > are problems I don't see. I definitely agree with Ramon and as an end > user would greatly appreciate such a feature. And as a web developer > taking good care of resources is also important. This strikes an > excellent balance. > > Jimmie > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> Subject: RE: [Seaside] Seaside sessions
> > I definitely would not want this as default, but perhaps as > decoration that one could use or a component to include as a > child as part of Seaside core? > > -Boris I didn't say I wanted it to be the default, it's simply a technique. The default is fine as it is. Ramon Leon http://onsmalltalk.com _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Oh, I know, I was responding to Jimmie's suggestion.
-Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Ramon Leon > Sent: Tuesday, September 04, 2007 8:31 AM > To: 'Seaside - general discussion' > Subject: RE: [Seaside] Seaside sessions > > > Subject: RE: [Seaside] Seaside sessions > > > > I definitely would not want this as default, but perhaps as > > decoration that one could use or a component to include as a > > child as part of Seaside core? > > > > -Boris > > I didn't say I wanted it to be the default, it's simply a technique. > default is fine as it is. > > Ramon Leon > http://onsmalltalk.com > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Ramon Leon-5
> > > Subject: RE: [Seaside] Seaside sessions > > > > I definitely would not want this as default, but perhaps as > decoration > > that one could use or a component to include as a child as part of > > Seaside core? > > > > -Boris > > I didn't say I wanted it to be the default, it's simply a > technique. The default is fine as it is. > > Ramon Leon > http://onsmalltalk.com Oops, ignore that, didn't realize you were replying to someone else. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Ramon Leon-5
Hey that's clever. Simple and still quite secure (unless users abandon open
browsers in connected hosts). I think I'll try this, thanks Ramon, Sebastian Sastre > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Ramon Leon > Enviado el: Martes, 04 de Septiembre de 2007 11:45 > Para: 'Seaside - general discussion' > Asunto: RE: [Seaside] Seaside sessions > > > -----Original Message----- > > From: [hidden email] > > [mailto:[hidden email]] On Behalf Of > > Sebastian Sastre > > Sent: Tuesday, September 04, 2007 6:22 AM > > To: 'Seaside - general discussion' > > Subject: [Seaside] Seaside sessions > > > > Hi there, > > > > there is any kind of good practice to use session in production? > > > > like an average duration that can be recomended? > > > > I saw that in basecamp one can be logged and hours > later add some > > record and it reponds fine. Can that behavior be implemented with > > seaside apps? if so, what approaches to implement that one can use? > > > > thanks, > > > > Sebastian > > I don't like web apps that timeout on me, nor do I like > wasting server resources with long session timeouts, so I > keep the 10 minute timeout and the root component of my apps > create a single perodical that does nothing that fires just > short of the session timeout to touch the server every so > often. This ensures any browser that is actually open won't > timeout and any actual unused sessions expires shortly. > > Ramon Leon > http://onsmalltalk.com > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Ramon Leon-5
Ramon Leon wrote:
>> Subject: RE: [Seaside] Seaside sessions >> >> I definitely would not want this as default, but perhaps as >> decoration that one could use or a component to include as a >> child as part of Seaside core? >> >> -Boris >> > > I didn't say I wanted it to be the default, it's simply a technique. The > default is fine as it is. > > Ramon Leon > http://onsmalltalk.com > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > I like it as well. Any plans to make a package of it? Maybe some kind of package of related techniques if it's too trivial on it's own to warrant a package. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf > Of Jason Johnson > Sent: Thursday, September 06, 2007 10:59 PM > To: Seaside - general discussion > Subject: Re: [Seaside] Seaside sessions > > Ramon Leon wrote: > >> Subject: RE: [Seaside] Seaside sessions > >> > >> I definitely would not want this as default, but perhaps as > >> decoration that one could use or a component to include as > a child as > >> part of Seaside core? > >> > >> -Boris > >> > > > > I didn't say I wanted it to be the default, it's simply a > technique. > > The default is fine as it is. > > > > Ramon Leon > > http://onsmalltalk.com > > > > _______________________________________________ > > Seaside mailing list > > [hidden email] > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > > I like it as well. Any plans to make a package of it? Maybe > some kind of package of related techniques if it's too > trivial on it's own to warrant a package. Seriously, it's nothing fancy, just a silly method in my SSComponent class, my WAComponent subclass I share across a few projects. It's to trivial to package. I do keep a package of my own experimental/learning stuff called SentorsaSeaside, which has always been semi available to anyone who downloaded my image from my blog. renderSessionKeepAliveOn: html html script: ((html updater) every: ((self preferenceAt: #sessionExpirySeconds) - 60) seconds; callback: []; yourself) Ramon Leon http://onsmalltalk.com _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
> renderSessionKeepAliveOn: html
> html script: ((html updater) > every: ((self preferenceAt: #sessionExpirySeconds) - 60) seconds; > callback: []; > yourself) Better use: html script: (html request every: (self preferenceAt: #sessionExpirySeconds) - 60) This is more lightweight from the JavaScript perspective and you don't even need to specify a callback. Lukas > > Ramon Leon > http://onsmalltalk.com > > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Jason Johnson-3
It could be added to Seaside28Jetsam, since this is exactly the kind of
small, useful addition for which Jetsam was conceived. I think it would be a cool thing to have, though a preference switch to enable/disable it would be good. Keith Ramon Leon wrote: >>> Subject: RE: [Seaside] Seaside sessions >>> >>> I definitely would not want this as default, but perhaps as >>> decoration that one could use or a component to include as a child >>> as part of Seaside core? >>> >>> -Boris >>> >> >> I didn't say I wanted it to be the default, it's simply a technique. >> The >> default is fine as it is. >> >> Ramon Leon >> http://onsmalltalk.com >> >> _______________________________________________ >> Seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> > > I like it as well. Any plans to make a package of it? Maybe some > kind of package of related techniques if it's too trivial on it's own > to warrant a package. > _______________________________________________ > Seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
I added this to Seaside28Jetsam-kph.17
- ext 15: WAKeepSessionAliveDecoration and WAJetsamConfiguration #keepSessionAlive This installs the above decoration of the root component in WARenderLoopMain-createRoot, if the configuration is enabled. This will not work for applications whose Main class sublcasses WARenderLoopMain but does not call super createRoot. i.e. Pier, though it is trivial to fix pier to do this. best regards Keith p.s. I would like to add the ShoreComponent's helper in the same way, so that ShoreComponents no longer needs a specialized root component. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
In reply to this post by Lukas Renggli
>
> > renderSessionKeepAliveOn: html > > html script: ((html updater) > > every: ((self preferenceAt: #sessionExpirySeconds) > - 60) seconds; > > callback: []; > > yourself) > > Better use: > > html script: (html request > every: (self preferenceAt: #sessionExpirySeconds) - 60) > > This is more lightweight from the JavaScript perspective and > you don't even need to specify a callback. > > Lukas Yea, but you have the unfair advantage of it being your code. ;) Excellent though, this is so old this is the first time I've looked at this thing in a year. Ramon Leon http://onsmalltalk.com _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |