Re: ISSUE-112: Should progress run a UI or rely on other stuff too?

On Sat, 10 Feb 2007, Charles McCathieNevile wrote:
> >
> > Are there any other actual use cases? What else would you use the 
> > progress events for if not a standard progress UI?
> 
> Measuring how your network operations are going, whether to time them 
> out andswap to something else, ...

Could you elaborate on this? It seems like this use case would need much 
stricter restrictions on frequency and timing of events. I didn't realise 
this was one of the requirements for this spec (and I definitely didn't 
realise it was the only requirement -- I'd assumed the intent was to do 
what Maciej described, but the existence of this issue clearly indicates 
that those use cases were not part of the initial requirements and 
research for this feature).


> The issue here though is actually whether you should be able to build 
> your entire UI on nothing but progress events, or whether you should 
> rely on other specifications for things like the start and end, and get 
> them to define that progress events can be fired.

I think it's clear that interoperability will be best served by having the 
events for each load feature described in conjunction with that load 
feature's processing model. It is extremely difficult to write unambiguous 
and implementable abstract specifications. (Not to say it's impossible, 
but it is certainly not something I would recommend.)


> In that scenario, if you build a UI element you would make a standard UI 
> widget that assumed no progress events, and a progress event extension 
> that, if it got them, would refine the UI widget by adding some sense of 
> progress. For example, a rectangular bar might normally have a cylon eye 
> effect, but if you get progress events that tell you how far along you 
> are you could change that to have a proportional progress bar.

Maciej's model seems amenable to this too. I don't think Maciej is arguing 
that the existing events (namely, 'load', 'error', and 'abort') should be 
dropped, or made redundant; I would expect his proposed processing model 
to augment them.


> As Maciej points out, that means you have to write widgets for each type 
> of operation that might fire progress events. On the other hand it means 
> you aren't relying on progress events in order to have at least some UI. 

I don't understand why we can't leverage the existing event structure 
while still providing for Maciej's use cases, and get easily authored 
backwards compatibility at the same time.


> And it lightens the requirements on the progress event spec.

Ease of spec writing should not be a concern here. There's an order of 
magnitude more implementors than spec writers, many orders of magnitude 
more authors than implementors, and yet more orders of magnitude more 
users than authors. Thus the needs of the users trump the needs of the 
authors, which trump the needs of the implementors, which trump the needs 
of the spec writers. We (the spec writers) are the slaves at the bottom of 
the chain -- on us falls all the hard work. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 10 February 2007 09:09:27 UTC