Re: Progress Use Cases (was Re: Progress event spec)

On Feb 7, 2007, at 11:05 PM, Charles McCathieNevile wrote:

> On Tue, 06 Feb 2007 17:39:31 +0530, Maciej Stachowiak  
> <mjs@apple.com> wrote:
>
>> On Feb 5, 2007, at 10:19 PM, Charles McCathieNevile wrote:
>>
>>> The progress and uploadprogress events are optional events that can
>>> be fired by
>>> (for an example) a user agent in the middle of an XmlHttpRequest  
>>> (XHR)
>>> transaction. The start and end of that transaction (whether
>>> successfully or in
>>> some error condition) are, in this example, predefined parts of XHR.
>>
>> The use case I presented was a reusable progress display control that
>> can connect to any possible event target that is a source of progress
>> events. Do you deny the validity of this use case, or do you have a
>> proposed alternate design that satisfies it?
>
> OK, I think I understand better what your use case is now. I don't  
> deny that it
> is a valid possible use case, and as you noted I don't think the  
> current draft
> satisfies it.
>
> My concern with it is that it requires more complexity in progress  
> events, and
> encourages a design that does not work for backwards compatibility.
>
> An alternative approach (the one I have been assuming) is that if  
> you have
> controls for specific things that may fire progress, and they use a  
> standard bit
> of rendering, you can attach the progress-based enhancements to any  
> of them.
>
> If we supported your use case, do you have an idea for how to write  
> a set of
> controls that also work as far as possible with existing user  
> agents, or are you
> suggesting we should simply ignore those?

Many likely progress targets already will fire one of "load", "error"  
or "abort", so those shouldn't be a concern with respect to   
backwards compatibility. Thus, the only new points of concern are  
"progress" (already in the spec, just a question of when it fires)  
and "loadstart". Unfortunately, there is no existing way to tell when  
a load starts in most progress targets. To make something backwards  
compatible you would need an out-of-band way to tell the control when  
you do something that may start a load. I think it would be  
unfortunate to lock that design in, however. It may be possible to  
special case this for some possible progress event targets such as XHR.

I think firing at defined times will be no more likely to result in  
code that does not fall back gracefully than leaving this completely  
undefined. And including load/error/abort in the spec will encourage  
authors to make use of those backwards-compatible events as well.

As for upload, all of these are brand new, there's no real  
possibility of a back-compatible design here. But having an  
uploadstart event will at least let you determine if your  
implementation supports upload progress at a fairly early state.

>
>>> It may never fire.
>>
>> If it's valid for the event to never fire, or to fire arbitrarily in
>> the middle of the load but not at the start or end, that makes it
>> much harder to use effectively in a way that works across
>> implementations. If one implementation sends start and end progress
>> events, and another doesn't, it is highly likely that code only
>> tested in one will fail in the other. I think interoperability is
>> more important than ease of implementing the spec in limited-resource
>> browsers.
>
> Representing an actual implementor of browsers in highly constrained
> environments I disagree that it is not important to support their  
> requirements.
> I also note that code developed for an implementation that does not  
> always send
> progress events is likely to work in one that does, so the  
> interoperability
> issue you allude to only arises if ignorant developers only test in
> implementations that happen to fire all possible events. (I don't  
> discount that
> possibliity, however).

Experience shows that thoughtful developers will test in many  
implementations, although if the implementations have very different  
behavior they may get confused and write code that breaks when one  
implementation changes to be more like another. And many developers  
will only test in one or perhaps two implementations. This includes  
even large web service companies, where many new services at launch  
are very broken in Safari and Opera, and sometimes even in Firefox.  
Even when developers initially test in many implementations, their  
ongoing testing may be in only one.

In conclusion, I think it's better to have a spec with well-defined  
requirements, and have browsers choose to either implement it or not,  
than to have something very loose. That way, at least there are only  
two possible behaviors.


>
>>> If you want to be compatible with the web, you can trap the
>>> start and end of an existing load. Since you have no progress
>>> information and
>>> don't know how long it will take, set up an indeterminate activity
>>> indicator
>>> like a spinning wheel or barber pole. If a progress event fires,
>>> and provides
>>> information you can use to determine more accurately the progress,
>>> then you can
>>> change the state of your indicator to reflect the new information
>>> (as you would
>>> anyway, no?). If you never get one, you can silently vanish, flash
>>> your bar full
>>> first, put a statement that you got an object of foo size (which
>>> you determine
>>> by measuring it) or whatever else makes you happy.
>>
>> Given the EventTarget interface, how do you measure the size of the
>> relevant object? Or for that matter, how do you measure the size in
>> bytes of the contents of an <img> element, or a parsed DOM document
>> in a frame, or the contents of an <svg:image>, or the contents of an
>> <object> tag handled by a plugin, even if you know the exact kind of
>> object you are dealing with?
>
> You can't, I suspect. How important is this?

Well, pretty important if one of your progress indicators is a size  
in bytes which remains onscreen after the load completes. And this is  
a common feature of many user interfaces.

Note, a possible alternate design for this is to require load/abort/ 
error events to implement the ProgressEvent interface and tell you  
the amount loaded and the total loaded, this would eliminate the need  
for the "last" progress event to be fired, but is likely to be  
somewhat less author-friendly.


>
>> I also don't understand why you are so insistent on using 0 length to
>> indicate indeterminate length rather than having a separate boolean
>> attribute for this with a clear name. In-band signalling is generally
>> considered poor API design. Even if this approach were not unworkable
>> it would lead to less clear user code [if (event.total != 0) vs if
>> (event.totalIsKnown) or the like].
>
> I'm not desperately attached to it. (Although for ECMAscript, our  
> most common
> target, can you not write
>
> if (event.total)
>
> anyway? I realise this is not portable across other languages  
> though, and
> recognise that this might not be ideal.

I think the extra boolean would be more clear.


>>> On Thu, 01 Feb 2007 08:18:45 +0530, Maciej Stachowiak
>>> <mjs@apple.com> wrote:
> ...
>>>> 2) You can't combine "loadstart" with "progress" [0,?,?]  
>>>> because: You
>>>> want to start showing feedback the moment loading starts, even  
>>>> if no
>>>> server response has yet told you what the content length will  
>>>> be, or
>>>> whether it is determinate, but you want to show the total or  
>>>> reflect
>>>> that it is unknown the moment that is the case.
>>>
>>> When loading starts you almost certainly don't know the total. If
>>> we outlaw
>>> progress events for zero-length transfers, you get it as [0,0] and
>>> it is clear
>>> you still don't know the total. Alternatively you may get [0,X] and
>>> can set up
>>> the determinate version before you start. But why would you rely on
>>> this anyway?
>>
>> I think you misunderstood my point, which was that you want to
>> display the total as soon as it is know (or certain to be unknown) at
>> the first progress event. This progress event may be 0 bytes in
>> length, or more, but will probably be sent as soon as the
>> implementation receives the http header or similar.
>
> True. But if we disallow a progress event for [0,0,true] (to use  
> your syntax as
> I understand it) then if you get a progress event for [0,0] you  
> know it is an
> unknown transfer size, and if you get [0,X] you know it is just the  
> first
> progress event fired when nothing has moved yet.

But in that case, when you get a "load" event, you won't know whether  
you just loaded an empty resource in an implementation that supports  
"progress", or a resource of whatever size in an implementation that  
does not.

>
>> I am quite certain that
>> you can't build one which can be attached to any plausible progress
>> event target.
>
> Indeed. However you can build a standard extension for dealing with  
> progress
> events, that can be attached to a standard UI control that would be  
> attached to
> any plausible source of progress events but where those events may  
> not be fired.

I'm not sure what this means.

> Anyway, I wil raise an issue, since I think we have a fundamental  
> difference in
> the most important use cases.
>
>> Consider also the XHR upload case, there is no obvious way to get the
>> total size of what you uploaded if it is a serialized DOM document
>> for instance. You could serialize it in what you hope is the same was
>> as XHR would do it, but this is not certain to be correct, and it is
>> quite expensive to do an extra serialization just to get the length
>> of the string. Plus, even then, you don't know the length of the
>> contents sent
>>
>> It seems much simpler to have an obviously complete set of progress
>> events than to play tricks with what you might be able to do with
>> fewer in some cases. What is the case against completeness?
>
> minimalism

I agree this is a worthy goal in general, however, minimalism cannot  
apply until you have achieved completeness. In this case, progress UI  
is the primary purpose for progress events, so they should make sure  
to support it.

Even for an API that provides a theoretically complete set of  
functionality, sometimes author-friendliness calls for more than the  
very absolute minimum.

> (and a desire to discourage developing things that are not  
> compatible with
> existing user agents).

I think we need to think of this in terms of making graceful fallback  
possible, rather than trying to push towards it. Any such  
encouragement should be in the form of authoring guidelines in the  
spec, rather than limiting the API itself.

Regards,
Maciej

Received on Thursday, 8 February 2007 08:41:48 UTC