On Sat, 27 Jan 2007 02:31:11 -0500, Ian Hickson <ian@hixie.ch> wrote:
> On Fri, 26 Jan 2007, Boris Zbarsky wrote:
>>
>> So I would hope that the spec says that not only is this implementation
>> defined but may differ depending on the actual network connection in
>> use....
>
> I haven't actually looked at the spec,
(Why tell us?)
> but, I would recommend something along the lines of:
>
> MUST fire at zero bytes
Because you can't disambiguate the case of an unknown length transfer and
a zero
byte total transfer at zero bytes transferred, I am not sure what this
buys you.
And I am not sure why it MUST fire at zero anyway - although in many cases
I
suspect that will be a useful point to fire and people will prefer
implementations that do that.
I don't think it MUST fire at all - authoring anything that relies on it
doing
so means breaking backpat for the sake of something that is really an
optional
extra, and since i don't see the gain yet I don't think it is a good idea
to
open that path.
> MUST fire again at the end, even if that is zero bytes
Agree with Jim on this.
> SHOULD fire at least once every 500ms in between the above two events,
> unless no progress has been made in that time.
> SHOULD NOT fire more than once every 10ms.
I don't think we need to be so prescriptive about the timing. There are
uses for
knowing that no progress has been made, and for a wide range of
frequencies (even
wider than the range of 2-100 Hz that you are suggesting). Is there some
reason
I am missing why that particular range makes special sense?
cheers
Chaals
--
Charles McCathieNevile, Opera Software: Standards Group
hablo español - je parle français - jeg lærer norsk
chaals@opera.com Try Opera 9.1 http://opera.com