- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 20 Oct 2009 20:45:16 +0200
- To: "Charles McCathieNevile" <chaals@opera.com>, "Ian Hickson" <ian@hixie.ch>
- Cc: "WebApps WG" <public-webapps@w3.org>
On Tue, 20 Oct 2009 20:00:27 +0200, Charles McCathieNevile <chaals@opera.com> wrote: > On Tue, 20 Oct 2009 13:14:00 +0200, Anne van Kesteren <annevk@opera.com> > wrote: >> Actually that request would not change anything. As far as >> XMLHttpRequest goes it would still transfer only a single entity. > > In the sense that it is a single transaction, sure. But conceptually it > is transferring something known to be divisible into a set of entities > (that's the point of the request :) ). Most things are divisible into a set of entities. Fact remains that we're dealing with a single entity body here as far as HTTP is concerned and that progress events are supposed to deal with entity bodies. Changing that for FormData does not make sense. >> I still agree with Ian that the progress event specification should not >> define at all which events are to be dispatched. It should give some >> guidance for event names, define the interface, and leave all the other >> normative details to other specifications. > > Yeah, I am sort of coming to that view. I still think it is useful for > the spec to give guidance about "normal usage", and for other specs to > follow common patterns, so authors don't have to learn a different and > conflicting kind of magic for each API that uses progress events. IMHO > that's one of the major reasons for having the spec in the first place. From what has happened so far around progress events I'm sort of doubtful the specification is the right coordination point for this. It seems review and communication works a lot better. -- Anne van Kesteren http://annevankesteren.nl/
Received on Tuesday, 20 October 2009 18:45:53 UTC