Re: Use cases (appcache, etc) [progress]

On Tue, 20 Oct 2009 13:14:00 +0200, Anne van Kesteren <>  

> On Tue, 20 Oct 2009 11:34:16 +0200, Charles McCathieNevile  
> <> wrote:
>> On Tue, 20 Oct 2009 10:26:08 +0200, Anne van Kesteren <>
>> wrote:
>>> The problem with this use case is that it does not map to any API. If  
>>> you would implement this the fetching of emails might happen over  
>>> XMLHttpRequest in which case there would only be one object at a time.
>> Sure. But note today's request [1] for allowing XHR to shift a  
>> collection of objects...
> 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 :) ).

> I do think it would make sense for appcache to have a progress event  
> that is dispatched more often that once for every file and in that case  
> the additional members would be of some use, though I'm not sure it  
> makes sense to have two meaningless members whenever XMLHttpRequest  
> dispatches a progress event. Should there be two interfaces, one  
> inheriting from the other?

Yes, I had sort of half thought that through (the constructor half) in  
today's draft. But it probably does make sense, and should also make  
people who have implemented something like the old version happier.

>> You are quite right that this is sailing close to the "inventing
>> technology in a standards group" wind. It makes me a little nervous.  
>> But I don't think it is completely inventing it - the disambiguation is  
>> based on real cases. It raises the issues of how the interaction works,  
>> which Ian asked about and at least Simon found obvious enough from my
>> half-baked preliminary explanation to explain quite quickly. It also
>> raises the question of what events fire per-object and what fire for
>> the whole transaction (ISSUE-107) which is directly relevant to
>> appcache anyway - i.e. is just a question of making sure that the
>> disambiguation is done cleanly without forgetting any obvious potential
>> clash.
> 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.



Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk       Try Opera:

Received on Tuesday, 20 October 2009 18:01:06 UTC