RE: New Progress Events spec

> > However, have you thought about widening the scope, to
> include things
> > like:
> > * Application timeouts (including the ability of AT to
> extend timeout
> > durations)
> 
> Can you please expand on the use case for this and how it would work?

A typical use case would be an online banking application that warns the
user 2 minutes before the session will time out (for security reasons).
Currently my online bank does this through opening a new window where the
user can opt for extending the session and stopping the current timeout
counter.

If there was an event for this, the user agent could act on it on behalf of
the user.  For example, it could extend the session for a user if the user
is still busy filling out the form.  This would be particularly important
for users with disabilities that sometimes require much longer time for
filling out forms, and would even miss to answer the timeout warning in
time.

But maybe that should even be a new event called "TimeoutEvent"?

Thanks,
Gottfried


> -----Original Message-----
> From: Charles McCathieNevile [mailto:chaals@opera.com]
> Sent: Saturday, March 17, 2007 12:25 AM
> To: Gottfried Zimmermann; 'web API'
> Cc: 'WAI PF public'
> Subject: Re: New Progress Events spec
> 
> 
> On Wed, 14 Mar 2007 07:13:22 -0700, Gottfried Zimmermann
> <zimmermann@accesstechnologiesgroup.com> wrote:
> 
> >
> > Charles,
> >
> > a couple of comments:
> >
> > (1) I think it would be useful to have (optional) information about
> > time included in the event, such as:
> > * elapsedTime
> > * estimatedTotalTime
> > * estimatedRemainingTime
> >
> > It seems that the originator of the ProgressEvent would
> have a better
> > chance to do a good estimation than the receiver, since it has
> > probably more knowledge about bandwidth, other traffic, etc.
> 
> Estimating the total or remaining time is in general (e.g.
> for network operations, but also for compilation and similar 
> extension use cases) just a guess based on what has happened 
> so far, and it seems to make more sense to me to leave that 
> to the consumer of the progress events.
> 
> Do we need to explicitly attach time information to the
> progress events, or is it already available? (I need to sleep 
> on this, or defer to someone who has the answer at their fingertips)
> 
> > (2) The current spec should not be called "ProgressEvent",
> but rather
> > "DownloadProgressEvent".  Its scope is restricted to a narrow use
> > case.
> 
> There is no reason it cannot be used for an upload, such as
> an HTTP PUT operation. Handling two-phase operations like 
> HTTP POST is noted as a current issue (see below) with a 
> proposed resolution.
> 
> > However, have you thought about widening the scope, to
> include things
> > like:
> > * Application timeouts (including the ability of AT to
> extend timeout
> > durations)
> 
> Can you please expand on the use case for this and how it would work?
> 
> > * Processing that requires a long time, e.g. compiling
> 
> This has been considered. In principle I believe there is
> nothing that prevents such a process from being a source of 
> progress events. The names of some of the events are chosen 
> for backwards compatibility with existing operations. If it 
> were clear how to measure the progress of some event other 
> than in terms of byte transfers it would be worth considering 
> how to do this, but I have not seen a clear proposal yet.
> 
> > * Whole transactions (not just downloading data)
> 
> There is an issue highlighted by the specific case of HTTP
> POST, where there is both an upload and a download component. 
> Our proposal is to require that an operation which has 
> progress in two phases provide two event targets for progress 
> events. As far as I know, it is not a priori possible to know 
> anything about the progress in advance of the actual 
> operation, so there is not much point trying to anticipate that.
> 
> cheers
> 
> Chaals
> 
> -- 
>   Charles McCathieNevile, Opera Software: Standards Group
>   hablo español  -  je parle français  -  jeg lærer norsk
> chaals@opera.com          Try Opera 9.1     http://opera.com
>

Received on Monday, 19 March 2007 07:47:00 UTC