Re: XMLHttpRequest progress events

On Apr 24, 2006, at 1:33 PM, Bjoern Hoehrmann wrote:

> * Maciej Stachowiak wrote:
>>> It rather seems like a bad idea to report progress of multi-gigabyte
>>> downloads with byte-precision. DOM Level 3 Load and Save does not  
>>> de-
>>> fine that the attributes represent a number of octets.
>>
>> What precision would you propose? It has to be defined to be able to
>> give a size to the user.
>
> What are the use cases for that exactly?

Many UI elements that give progress feedback on a download show the  
size in bytes (or KB or MB or GB for larger sizes) as well as a  
proportional or percentage amount. For example, the download window  
in Safari shows size so far out of total size. Flash splash screens  
also sometimes show (kilo)bytes loaded out of total. You could argue  
that XMLHttpRequest will never be used in a situation where this kind  
of progress feedback is desired, but that seems like a rather bold  
assumption.

> You can determine a percentage
> of progress no matter whether the numbers are in bytes or gigabytes or
> whatever, and it is not clear to me that the numbers would be meaning-
> ful if, say, the user agent is behind a data compression proxy, or how
> any specific unit would be appropriate if you could use a protocol  
> where
> you don't know the totalSize until late in the transfer, and consider
> cases where multi-gigabyte resources might be transferred with XHR. If
> the concern is making [ x bytes of y bytes ] style widgets, I'd  
> suggest
> we agree on use cases first, and then discuss syntax.

Yes, the concern is precisely for such widgets. The are used today in  
various places on and off the web, I do not think the API should be  
designed so as to rule them out. Your examples of complicated cases  
are interesting but I think just using a larger numeric type  
(floating point double? 64-bit int?) with a unit of bytes would  
address them fine, or at least as well as an unspecified unit would.

Regards,
Maciej

Received on Tuesday, 25 April 2006 09:22:18 UTC