W3C home > Mailing lists > Public > public-webapi@w3.org > January 2007

Re: Progress event spec

From: Charles McCathieNevile <chaals@opera.com>
Date: Sat, 27 Jan 2007 21:21:27 -0500
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: "SVG working group" <w3c-svg-wg@w3.org>, "Web API public" <public-webapi@w3.org>
Message-ID: <op.tmud510nwxe0ny@widsith.local>

[Please follow up only to webapi...]

On Sat, 27 Jan 2007 19:14:24 -0500, Maciej Stachowiak <mjs@apple.com>  
wrote:

>
> On Jan 26, 2007, at 1:54 PM, Charles McCathieNevile wrote:
>
>>
>> Hi,
>>
>> following our face to face meeting, we are planning some changes to
>> progress:
>
> Based on my experience designing the Objective-C API that drives the
> progress bar and other progress indicators in Safari, I think these
> proposed changes make the API unsuitable for common UI use cases.
>
>>
>> 1. Make the "total" attribute 0 if the length is unknown, and drop
>> the boolean "lengthComputable".
>>
>> The rationale is that if you really have a zero-length load, it is
>> unlikely to
>> ever have time to fire a progress event, and will almost certainly
>> only fire any
>> in a really degenerate case. Having a large number was a bad idea,
>> since one day
>> you will have a large number of bytes, and having anegative number
>> meant having
>> a signed instead of unsigned integer.
>
> That means on the first progress event, if there is no data, 0
> progress out of a 0 total is indistinguishable from 0 progress out of
> an indeterminate total. I think one common case for these events will
> be to drive progress UI. Generally, common user interface toolkits
> have different widgets for indeterminate and determinate progress.
> This way, you can't tell which one to display on the first event.

Agreed in principle. In practice, we felt that you were unlikely to get a
progress event with a value 0 except in the indeterminate case - if you  
know
that you are transferring 0 of a total of 0 bytes you simply fire the load  
event
instead rather than setting up and instantly destroying a transfer widget.  
(If
you want to do that, you can do it on load completing if you hadn't got a
progress event yet...)

> But
> on the other hand, the network layer almost always knows the total is
> indeterminate very early, so having a "totalKnown" or
> "lengthComputable" boolean or whatever is no great burden.
>
>> 2. Remove the preload and postload events.
>>
>> You know when it finished, because the load event or whatever is
>> spitting out progress will have finished.
>
> Would all things subject to progress events have a "load" event as
> well? If so, I am ok with this. Otherwise, you can't tell when
> something with an indeterminate total is done, so I would object.

This is the crux of the issue. I would be interested in a use case for a
progress event that doesn't do this.

> Note also that many things currently subject to "load" events have
> weird rules for when it does and doesn't fire (as opposed to the
> "error" event or none at all).
>
>> You know when it started, because you got a progress event.
>
> The moment the load starts, the total is not known, and there are 0
> bytes received, but with many protocols (for instance http) you will
> know the total at or before the time the first data chunk is
> received. Given this, I think it's good to have an event that tells
> you when the connection has been initiated, before when you get any
> network response back; the latter should be a progress event.

Right. That is perfectly in line with what you can do under the current  
spec,
but we don't force it...

>> 3. Add an uploadprogress
>>
>> It is possible to construct an XHR that is moving content up and
>> down at the
>> same time, so knowing when progress refers to one or the other is
>> useful.
>
> This seems like a good change.
>
>> 4. Rename loadprogress to progress
>>
>> It's shorter.
>
> Seems ok but I wonder whether the event is appropriate for non-
> loading cases of progress, and whether such cases will come up.

Me too. In principle you might have a script which sends progress events  
as it
does some monstrous calculation on a table or something, and it wouldn't  
load.
It also wouldn't be transferring bytes. So it might do something that  
looks very
similar but is defined seperately. Should we be covering that range of use  
case
in this spec, or leave it for authors or a later group to spec out?

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 Sunday, 28 January 2007 02:21:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:56 GMT