Re: XMLHttpRequest progress events

On Apr 24, 2006, at 9:29 AM, Boris Zbarsky wrote:

> Maciej Stachowiak wrote:
>> I understand that as an implementor you don't want to sit around  
>> waiting for standards bodies to include features in a spec before  
>> implementing them. However, since there is an active, open and  
>> healthy standards process going on here, you may want to try  
>> participating in it more actively before taking that approach.
>
> Well, that's what I was trying to do with my initial mail.  ;)
>
> Here goes:
>
> ---------------------------------------------------------------------- 
> ----
> Listeners registered for the "progress" event on the XMLHttpRequest  
> object may receive events implementing the LSProgressEvent  
> interface as data is returned from the server.  This event will  
> have a null |input| property.  The |totalSize| property will be  
> 0xFFFFFFFF if the total size is not known.

That's not 64-bit clean. In WebKit at least our network library can  
support correctly reporting progress for files that are larger than  
2^32-1. Seems like a bad idea to limit this with large media files  
and large amounts of memory becoming more and more common. This  
probably argues against using LSProgressEvent as-is. It's too bad  
they used "unsigned long" (which is a 32-bit integer type in OMG IDL).

The DOM Level 3 Load & Save spec also says:

"A value of 0 is returned if the total size cannot be determined or  
estimated."

Your proposal for unknown size is incompatible with this.

Between this and the always-null input attribute, it seems re-using  
LSProgress might not be that useful, although using the same names  
for the applicable attributes may still be a good idea.

> Listeners registered for the "uploadprogress" event on the  
> XMLHttpRequest object may receive events implementing the  
> LSProgressEvent interface as the request is sent to the server.   
> This event will have a null |input| property.  The |totalSize|  
> property will be 0xFFFFFFFF if the total size is not known.
>
> Implementations are not required to fire these events, but are  
> strongly urged to so that XMLHttpRequest consumers can implement  
> progress indicators as desired. If progress events are fired, there  
> is no specific requirement for how often they should be fired.

I think it might be better to define this in a way that has some  
testable conformance criteria. It's hard to rely on if  
implementations are allowed to do anything (including send no  
progress events at all, send them at the wrong time,

I realize in this case that's hard to do without needlessly  
overconstraining the implementation. But here are some requirements  
that I think might not be unreasonable:

1) You'll get at least one progress event for the full size of the  
resource. That way you can always use this event alone to make a  
progress bar, although the granularity may be very poor.

2) If you ask for responseText, you are guaranteed to see at least as  
much decoded data as the last progress event reported.

3) Might want to define when progress events occur relative to  
readystatechange events - I'm not sure what this should even be.

Regards,
Maciej

Received on Monday, 24 April 2006 17:04:46 UTC