Re: Use cases (appcache, etc) Re: Using progress events for other purposes

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.


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


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

Received on Tuesday, 20 October 2009 08:26:46 UTC