- From: Jim Ley <jim@jibbering.com>
- Date: Tue, 25 Apr 2006 09:46:01 +0100
- 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 UTC