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

On Tue, 20 Oct 2009 10:26:08 +0200, Anne van Kesteren <annevk@opera.com>
wrote:

> On Tue, 20 Oct 2009 02:10:43 +0200, Charles McCathieNevile  
> <chaals@opera.com> wrote:
>> On Mon, 19 Oct 2009 20:13:23 +0200, Anne van Kesteren  
>> <annevk@opera.com> wrote:
>>> If only a subset of the attributes ends up being used, i.e. appcache  
>>> is not going to dispatch progress events more often than one per file,  
>>> I do not think this feature is worth it to be honest. Because for  
>>> appcache total and loaded would always be 0 and for XMLHttpRequest  
>>> totalItems and loadedITems would always be 0.
>>
>> Quite true. The hypothesis is that appcache may end up dealing with  
>> files where progress events *are* disaptched more than once per file,  
>> for example collecting a cache which has a 1MB video over a slow line.
>
> I suppose, but the specification would have to change first.

Or someone could just implement this (since it is foreshadowed as a
possibility) and then suggest the spec change. That happens quite a lot,
and is one of the reasons for coordinating loosely coupled but seperate
specs.

>>> Are there any other cases worth considering?
>>
>> The other use case [1] that motivated this was a mail client  
>> downloading a number of distinct emails as objects, where some of them  
>> could be very large.
>>
>> My assumption is that these are real use cases, which is why I made the  
>> proposal (and bothered doing the thinking to try and spec it out). It's  
>> up to the group to decide, of course.
>>
>> [1] http://www.w3.org/mid/op.u0xi82ucwxe0ny@widsith.eng.oslo.osa
>
> 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.

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

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

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
       je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Tuesday, 20 October 2009 09:35:00 UTC