- From: Charles McCathieNevile <chaals@opera.com>
- Date: Sat, 27 Jan 2007 11:28:14 -0500
- To: "Ian Hickson" <ian@hixie.ch>, "Boris Zbarsky" <bzbarsky@mit.edu>
- Cc: João Eiras <joao.eiras@gmail.com>, "Web APIs WG" <public-webapi@w3.org>
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
Received on Saturday, 27 January 2007 16:28:28 UTC