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

Re: Progress event spec

From: Joćo Eiras <joao.eiras@gmail.com>
Date: Fri, 26 Jan 2007 23:52:00 -0000
To: "Web APIs WG" <public-webapi@w3.org>
Message-ID: <op.tmsckyezjz3wb9@dragast>

I too have a question.
If I'm downloading say 50kb, how many times will the progress event fire ?  
Now if I'm downloading 1MB how many times will it fire ?
I doubt it'll fire every byte, else listening for this event will consume  
enormous amounts of cpu. I too doubt it'll fire every kilobyte, else the  
previous scenario will easily apply on a fast connection. I doubt it'll  
fire every megabyte, else it'll be useless for slow connection or files  
smaller than 1mb.
Please don't tell me it's implementation defined, else interoperability  
will be the same old headache for minoritary browser vendors.

And a suggestion: in the spec I read "@@Issue: Does it bubble / is it  
cancelable? I am not sure why it would / be, myself."
It should only bubble and have as target the related document, or xhr  
object, just like the load event.

Charles McCathieNevile <chaals@opera.com> escreveu:

>
> Hi,
>
> following our face to face meeting, we are planning some changes to
> progress:
>
> 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.
>
> 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. You know when it started, because you got a
> progress event.
>
> 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.
>
> 4. Rename loadprogress to progress
>
> It's shorter.
>
> Do any of these changes cause any great heartache or seem crazy? I  
> haven't
> updated the draft at http://dev.w3.org/cvsweb/2006/webapi/progress/ yet  
> but I
> will try to do that ASAP so we can request first public working draft.
>
> cheers
>
> Chaals
>
Received on Friday, 26 January 2007 23:52:02 GMT

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