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
