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 Friday, 16 March 2007 23:25:06 UTC