W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

Re: XMLHttpRequest progress events

From: Jim Ley <jim@jibbering.com>
Date: Tue, 25 Apr 2006 09:46:01 +0100
Message-ID: <00c101c66844$ae7e1080$2402a8c0@Snufkin>
To: "Web APIs WG \(public\)" <public-webapi@w3.org>

"Bjoern Hoehrmann" <derhoermi@gmx.net>
> * Jonas Sicking wrote:
>>In many cases the user might know the size even if the implementation
>>does not. Or it is even imaginable that the script knows the size even
>>if the XHR class does not. In both these cases the number of bytes
>>transferred is useful to present.
>
> Right, they have currentSize = knownSize * position/total for that, no?

position and total rely on the XHR knowing the size, as it's often not 
likely to, using bytes is a sensible way of giving maximum amount of 
information.  It's also possible that it's the user and not anyone else who 
is the only person likely to know the size.

This is also how other progress events I've experience with work.

The use cases for progress are related to providing indications to the user 
of how things are going. Or to providing indications to the client of a good 
time to process the incoming stream - ie knowing 10k's arrived it's worth 
firing off a process of the first 10k.  Lots of my uses of streaming data to 
script can't provide a content-length (because then I'd have to buffer the 
results on the server before I can send...)

Given that without information of content-length the UA can't offer anything 
else, bytes are a good choice all round.

Cheers,

Jim. 
Received on Tuesday, 25 April 2006 08:46:26 GMT

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