I have been watching this thread, I have another use-case. What if the user
has a form on the screen, simply to View the information? Clicks the OK
button as they do because that's what they have always done. Which in
general cases will do a submit. But the session has timed-out because they
didn't actually change anything, nor did they even touch an input field.
I am for a Ping and I agree with Leigh's idea. How about when the user
leaves an input field a ping is sent and the ping timer is reset. If a
timeout of X seconds has occurred since the last ping the timer will send an
automatic ping. Then the ping is reset again. I hope this is clear.
Unfortunately I just have too much work at the moment to spend time on the
serialization of sessions which I also believe will be useful.
Regards
Scott Warren
Ocom Software
... Exceeding Quality.....
web | ocom.com.au
> -----Original Message-----
> From:
> chiba-developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> [mailto:chiba-
> developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx] On
> Behalf Of Klotz, Leigh
> Sent: Tuesday, 19 December 2006 11:33 AM
> To: joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx
> Cc: chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> Subject: Re: [Chiba-developer] timingissuesin
> XFormsSessionManager/DefaultXFormsSessionManager
>
> Sorry I meant DWR, not DRM ;-)
>
> I believe the easy case is the one I solved, and shouldn't require any
> additional markup.
> - The user is interacting with the form,
> - but @incremental isn't set,
> - and the form controls themselves don't happen to require any DWR
> interactions,
> - so they don't send anything
> - so the Chiba session doesn't know the user is there.
> Therefore, eventually it times out.
>
> So I propose a simple change in the behavior of the Flux JavaScript:
>
> - The user is interacting with the form,
> - but @incremental isn't set,
> - and the form controls themselves don't happen to require any DWR
> interactions,
> - so the onfocus/onblur/onclick/onkeydown handlers on the form controls
> check the time of the last DWR action
> - and if the last DWR interaction was more than a minute ago, it sends a
> keepalive.
> - so the Chiba session *knows* the user is there.
> Therefore, it doesn't time out.
>
> This doesn't fix timeouts for the StandardServlet (non-Flux).
>
> Leigh.
>
>
> -----Original Message-----
> From: joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx
> [mailto:joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx]
> Sent: Monday, December 18, 2006 4:22 PM
> To: Klotz, Leigh
> Cc: Adam Retter;
> chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> Subject: Re: [Chiba-developer] timing issuesin
> XFormsSessionManager/DefaultXFormsSessionManager
>
> Klotz, Leigh wrote:
> > We found that typing in a textarea could lead to session timeout, so
> we
> > put in a ping feature every minute or so as long as there is activity
> on
> > controls. @incremental satisfies it already. Probably the check
> should
> > have been done on most recent DRM call rather than at the ping and
> event
> > level, to have the optimal elimination of unnecessary pings.
> Leigh,
>
> yes, your use case has been heart and accepted as a general problem and
> i've searched for generalizing an approach to such situations.
>
> I've come up with several thoughts/ideas:
> - first, we've implemented a 'pulse' feature for any form by adding a
> <chiba:keepalive pulse="900"/>
>
> element as first child under the root of the document. This allows to
> add a ping to every form that might use it. The problem with this
> approach is that it effectively disables server-side session management
> and should be used with caution. This way a forms session would never
> expire unless the user leaves in a defined way.
>
> - second, Scott brought up the serialization topic again. If Chiba
> XFormsSessions could be persisted after their timeout has happened and
> deserialized when the user comes back then the problem of forms timing
> out would become pointless. This is a larger change though Scott has
> done some nice groundworks in the right direction.
>
> - third i've thought about adding an chiba element to allow the author
> to set the XFormsSession timeout per form. Different forms have very
> different usage situations and a global timeout for every form might not
>
> be appropriate. Together with the second point (so you can steer how
> long your form lives before you've to take the cost of
> (de)serialization) this looks like the most promising solution to me.
>
> But what exactly do you mean by 'the check should have been done on most
>
> recent DRM call ..."? Of course i'm interested in further options and
> ideas to address this issue.
>
>
> >
> > Without some sort of ping feature, users working on forms with big
> text
> > areas lose their work and are unhappy.
> >
> > -----Original Message-----
> > From:
> > chiba-developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> > [mailto:chiba-developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx]
> > On Behalf Of
> > Joern Turner
> > Sent: Friday, December 15, 2006 1:39 PM
> > To: Adam Retter
> > Cc: chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> > Subject: Re: [Chiba-developer] timing issuesin
> > XFormsSessionManager/DefaultXFormsSessionManager
> >
> > Adam Retter wrote:
> >> 1) XFomsSessionManager.setTimeout() the parameter is named
> > milliseconds,
> >> but the javadoc says seconds - which is it?
> > millis
> >
> >> 2) XFormsSessionManager.setInterval() the parameter is not named and
> >> there is no javadoc, is this seconds or milliseconds?
> >>
> >> 3) DefaultXFormsSessionManager.DEFAULT_TIMEOUT is set to 5000, with
> > the
> >> comment that its 5 minutes, however if this is in milliseconds that
> >> would be 5 seconds, if its in seconds it should be 300 not 5000.
> > ok, should be fixed
> >
> >> 4) DefaultXFormsSessionManager.interval is set as 1500, the parameter
> > of
> >> DefaultXFormsSessionManager.setInterval() implies that this is in
> >> milliseconds. So this would be 1.5 seconds, this seems very short?
> > right. This value might still be present from testing. This feature
> > actually is not very stable. Though working i didn't intend to
> > communicate it's existence ;) since the whole issue has been
> clarified.
> >
> > The context here is the requirement to have sessions that don't expire
>
> > because of long intervals between values updates through the user.
> This
> > pulse feature was one attempt to solve that but it does not convince
> me
> > yet. The better solution here would be to have persistent sessions
> that
> > are persisted when there's risk to loose data through session expiry.
> >
> > To cut it short if there are not strong arguments to keep the pulse
> > feature we'll probably remove it again.
> >> 5) ChibaServlet.createXFormsSession() line 443:
> >> manager.setTimeout(1000 * 30); // 1 minute session lifetime
> >> Assuming that setTimeout() should be set in milliseconds, this set's
> > it
> >> to 30 seconds, not 1 minute as the comment describes.
> >>
> >> I would be happy to tidy up and fix these issues is someone can
> > clarify
> >> whats what...
> >>
> >> Thanks
> >>
> >>
> >
> >
> >
> ------------------------------------------------------------------------
> > -
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
> share
> > your
> > opinions on IT & business topics through brief surveys - and earn cash
> >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> > V
> > _______________________________________________
> > Chiba-developer mailing list
> > Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/chiba-developer
> >
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Chiba-developer mailing list
> Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/chiba-developer
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
|
