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

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?

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

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

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

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

>>> 3) You can't combine the final "progress" with "load" because: if you
>>> only have "load", there's no way to know the final total of bytes in
>>> the indeterminate case,
>>
>> This is true, if you can't measure the thing you loaded. What is
>> the use case for that?
>
> Already stated - reusable progress control. Say I have my <html:img>
> element firing progress events. How do I "measure the thing [I've]
> loaded" in that case? If we are designing this API solely for the use
> of XHR then it should be in XMLHttpRequest 2.0, not a separate spec.
> If it is meant to be reusable, then it should be designed to be
> complete.

I agree that we should give this spec what it needs for reusability.

>>> It may sound overengineered to have so many
>>> events, but it's the only way to make it possible to build correct
>>> UI.
>>
>> We have some of these events already in whatever specification (XHR
>> is an
>> example) is going to use progress events. I believe that relying on
>> those makes
>> it possible to build correct UI.
>
> It may be possible to build an XHR-only one, although I do not think
> you have demonstrated even that. It should be very easy to copy my
> charts and annotate them with what event is guaranteed to happen
> when, and what the UI does in response to it.

Yes, but it takes a little time. It's coming...

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

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

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

cheers

Chaals


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

Received on Thursday, 8 February 2007 07:05:46 UTC