Re: Using progress events for other purposes

On Sun, 27 Sep 2009 20:20:52 +0200, Ian Hickson <ian@hixie.ch> wrote:

> On Sun, 27 Sep 2009, Charles McCathieNevile wrote:
>>
>> The alternative is to think now about extending Progress Events to deal
>> with non byte-length progress (e.g. a series of transactions, each of
>> which is very rapid alone but which add up to minutes).
>>
>> My preference would be to create new attributes for this case rather
>> than overload the total/loaded attributes. A third approach would be to
>> have a flag which specifies whether the total/loaded attributes measure
>> bytes, and a related fourth would be to have an attribute that says what
>> the total/loaded attributes are measuring.
>>
>> I have raised ISSUE-105 for this question.
>
> It's not clear to me why the current ProgressEvent interface couldn't be
> used as-is, other than the Progress Events spec saying so.

That is indeed the only reason currently (and obviously it didn't stop you  
putting it into an HTML5 draft, so it doesn't seem to be a strong reason  
:) ).

> It's not like the events could be confused with events where bytes are
> intended, in this particular case.

True. The question is whether this particular case is representative - one  
use case isn't always a great basis for deciding a set of requirements.

So in the interest of helping explain my thinking (and making me think  
further), I am also wondering about the following use case:

I want a web application that fetches mail, and it wants to specify  
progress both in terms of the number of messages transferred, and where a  
transfer lasts more than a quarter of a second, progress in fetching that  
message. (This is carefully made up by looking at my current mail client).  
A simple way to do this would be to fire a progress event at the  
completion of each message being received, and to fire one every  
quarter-second during a transfer where the message is big enough or moving  
slowly enough to hold up progress.

But it isn't clear to me how easy it is to distinguish these messages -  
while I haven't written the code, it seems to me that I want to fire  
events on basically the same targets. So it isn't clear how I would hook  
them up to do something useful.

A similar question arises for me in application cache itself, where I want  
some files that are very big, and some that are very small, in a parallel  
manner. (Very big just means "to big to move more or less  
instantaneously". There are plenty of widgets bigger than 1MB and plenty  
of networks that make that take real time, and implementations pop up real  
progress bars now on downloading).

This is what leads me to question the approach you have taken so far.

A solution may be to look at the targets of the events as the  
distinguishing feature, but in my head I don't see a clear way to do that.  
I would therefore appreciate further input.

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 Sunday, 27 September 2009 19:04:51 UTC