"Bjoern Hoehrmann" <[EMAIL PROTECTED]>
* 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.
