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

On Tue, 20 Oct 2009 11:34:16 +0200, Charles McCathieNevile  
<chaals@opera.com> wrote:
> On Tue, 20 Oct 2009 10:26:08 +0200, Anne van Kesteren <annevk@opera.com>
> 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. The current pattern of having to zip up a bunch of things, or
> make multiple XHR transfers, works. But in some cases it is frustrating.

Actually that request would not change anything. As far as XMLHttpRequest  
goes it would still transfer only a single entity.


>> Other than appcache there is no API that I know of that downloads  
>> multiple separate objects of which the total is sort of known in  
>> advance.
>
> No, I don't know of an API today that does this either, although I know  
> of various use cases. My proposal assumes that these use cases will lead  
> to
> such an API. Disambiguating the appcache case from the XHR case now  
> allows for such an API to use the spec as is, while in practice  
> implementations
> may or may not do something with the full possibility before such APIs  
> are specified.

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?


> 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.


> I should be clear that I haven't yet checked closely with the guys at
> Opera who would implement this whether they think it makes sense - and I
> may yet withdraw the proposal on the grounds that it is just too complex.
> But it seems to me worthwhile investing a bit of my time to make them  
> (and everyone else) a proposal that is sufficiently fleshed out for them  
> to at
> least make that judgement.
>
> [1]  
> http://www.w3.org/mid/bd8f24d20910192355p4fe48531n965c0198039afa5d@mail.gmail.com


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Tuesday, 20 October 2009 11:14:44 UTC