New Progress Events spec

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

New Progress Events spec

Charles McCathieNevile-2

http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.8

I would appreciate review, and in particular propose to publish this spec as a First Public Working Draft more or less in its current shape.

All other comments and criticisms are of course appreciated...

cheers

Chaals

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

Reply | Threaded
Open this post in threaded view
|

Re: New Progress Events spec

Ian Hickson

On Wed, 7 Mar 2007, Charles McCathieNevile wrote:
>
> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html

Early comments:

XmlHttpRequest should be XMLHttpRequest.

I disagree with "in general specifications should not specify that
progress events must occur". I don't think requiring these events causes
any backwards incompatibilities. The incompatibility is if someone in new
content assumes those events take place, but that will happen whether or
not a requirement uses a SHOULD requirement. In fact the entire
"Considerations for Backward Compatibility" section doesn't really make
any sense to me.

I think the event 'progressStart' should be called 'start'.

I think the event 'progressError' should be 'error' for backwards
compatibility.

I think the event 'progressCanceled' should be 'abort' for backwards
compatibility.

I think the event 'progressComplete' should be 'load' for backwards
compatibility'.

The spec doesn't say how to decide whether to fire 'error' or 'abort'.

The spec implies that 'error' and 'abort' are not mutually exclusive with
'load'.

The spec says that the events must be cancelable but does not define their
default action.

The initialisation methods for ProgressEvent are missing a
lengthComputableArg argument in the IDL.

The following requirement both abuses RFC2119 terminology and makes no
sense from a conformance point of view: "This method may only be called
before the progress event has been dispatched via the dispatchEvent
method, though it may be called multiple times during that phase if
necessary."

The specification is lacking requirements on user agents to set the event
attributes appropriately.

I would recommend changing the start of the "The ProgressEvent events"
section to more clearly indicate exactly what it is other specifications
are to do. As it stands I don't know that I'd be able to appropriately use
this specification to write another one that uses these events in a fully
well-defined and unambiguous way.

Please have Bjoern review this specification for consistency with DOM3
Events.

The acknowledgements refer to the "WHATWG progress event proposal" as
being "invaluable in preparing this draft", but that seems unlikely since
there is no such proposal (the provided reference is to the <progress>
element, a UI widget).

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

Reply | Threaded
Open this post in threaded view
|

Re: New Progress Events spec

Maciej Stachowiak
In reply to this post by Charles McCathieNevile-2


On Mar 6, 2007, at 6:02 PM, Charles McCathieNevile wrote:

>
> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/ 
> Progress.html?rev=1.8
>
> I would appreciate review, and in particular propose to publish  
> this spec as a First Public Working Draft more or less in its  
> current shape.

I think it's fine for FPWD, other comments notwithstanding.

> All other comments and criticisms are of course appreciated...

I'll mostly try not to duplicate Ian's comments, though I agree with  
many, but two stand out as worth repeating:

- The terminal events should be load/abort/error rather than  
progressComplete/progressCancel/progressError, for better backwards  
compatibility.

- The spec should not recommend that other specs make dispatch of  
progress events optional. Specifications add new features over time,  
and it doesn't make sense to require all new features to be optional.  
Nothing about progress events makes them a special case for this.

Other comments:

- Conformance section -- the spec should define conformance classes.  
I suggest "conforming implementation" and a conformance class for  
specs that define use of progress events, much like the conformance  
classes for the access-control spec.

- "A progress event occurs when the user agent makes progress in some  
network operation" -- perhaps this should be "data transfer  
operation", as it might not necessarily be over a network.

- "User agents may dispatch one or more ProgressEvent of type  
progress while a network operation is taking place." -- per my  
earlier use cases document, I'd like to suggest requiring dispatching  
at least one as the size is known (or definitely known to be unknown).

- "These events must not bubble, and must be cancelable." -- I  
suggest making these not cancelable, since there's no default action  
to prevent.

- "readonly boolean lengthComputable" -- I suggest renaming this to  
"totalKnown", to avoid arbitrary inconsistency with the name of the  
"total" attribute, and because "known" is more accurate than  
"computable".


Regards,
Maciej


Reply | Threaded
Open this post in threaded view
|

Re: New Progress Events spec

Charles McCathieNevile-2
In reply to this post by Ian Hickson

To+: Bjoern. Bjoern, could you please review this specification for compatibility with DOM3 events?

On Wed, 07 Mar 2007 13:19:46 +1100, Ian Hickson <[hidden email]> wrote:

> On Wed, 7 Mar 2007, Charles McCathieNevile wrote:
>>
>> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html
>
> Early comments:

Thanks for these. There is a new draft, incorporating some changes as discussed further below...

> XmlHttpRequest should be XMLHttpRequest.

Yup.

> I disagree with "in general specifications should not specify that
> progress events must occur".

Me too, and removed it.

> I don't think requiring these events causes
> any backwards incompatibilities. The incompatibility is if someone in new
> content assumes those events take place, but that will happen whether or
> not a requirement uses a SHOULD requirement. In fact the entire
> "Considerations for Backward Compatibility" section doesn't really make
> any sense to me.

Hmm. This draft marks a change in underlying assumptions. Having thought about it, I removed that section as it doesn't seem applicable to the new approach.


> I think the event 'progressError' should be 'error' for backwards
> compatibility.
>
> I think the event 'progressCanceled' should be 'abort' for backwards
> compatibility.
>
> I think the event 'progressComplete' should be 'load' for backwards
> compatibility'.

All these are fine by me.

> The spec doesn't say how to decide whether to fire 'error' or 'abort'.
>
> The spec implies that 'error' and 'abort' are not mutually exclusive with
> 'load'.

The spec doesn't mention 'error' or 'abort', but the ways to arrive at various end states are indeed not clearly distinguished. @@ToDo

> The spec says that the events must be cancelable but does not define their
> default action.

Right. Do you have a suggestion for a default action? Is there a reason we need one for everybody to implement?

> The initialisation methods for ProgressEvent are missing a
> lengthComputableArg argument in the IDL.

Whoops. Fixed.

> The following requirement both abuses RFC2119 terminology and makes no
> sense from a conformance point of view: "This method may only be called
> before the progress event has been dispatched via the dispatchEvent
> method, though it may be called multiple times during that phase if
> necessary."

Could you explain what you mean by "makes no sense"? Tightening up the use of RFC 2119 terminology is one thing, but the idea seems simple to me.

> The specification is lacking requirements on user agents to set the event
> attributes appropriately.

Yep.

> I would recommend changing the start of the "The ProgressEvent events"
> section to more clearly indicate exactly what it is other specifications
> are to do. As it stands I don't know that I'd be able to appropriately use
> this specification to write another one that uses these events in a fully
> well-defined and unambiguous way.

That section could be significantly improved to make it easier and help it happen in an interoperable way. @@ToDo

> Please have Bjoern review this specification for consistency with DOM3
> Events.

I have as much control over Bjoern as you do, but this is explicitly cc'ed to him as a request that he takes a look.

> The acknowledgements refer to the "WHATWG progress event proposal" as
> being "invaluable in preparing this draft", but that seems unlikely since
> there is no such proposal (the provided reference is to the <progress>
> element, a UI widget).

Yep. Fixed.

Cheers

Chaals

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

Reply | Threaded
Open this post in threaded view
|

Re: New Progress Events spec

Charles McCathieNevile-2
In reply to this post by Maciej Stachowiak

On Wed, 07 Mar 2007 14:13:58 +1100, Maciej Stachowiak <[hidden email]> wrote:

>
> On Mar 6, 2007, at 6:02 PM, Charles McCathieNevile wrote:
>
>>
>> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/
>> Progress.html?rev=1.8
>>
>> I would appreciate review, and in particular propose to publish
>> this spec as a First Public Working Draft more or less in its
>> current shape.
>
> I think it's fine for FPWD, other comments notwithstanding.

Thanks, and thanks for the comments. I have made a new draft with some changes incorporated as discussed below...

>> All other comments and criticisms are of course appreciated...
>
> I'll mostly try not to duplicate Ian's comments, though I agree with
> many, but two stand out as worth repeating:
>
> - The terminal events should be load/abort/error rather than
> progressComplete/progressCancel/progressError, for better backwards
> compatibility.

Yep, implemented now.

> - The spec should not recommend that other specs make dispatch of
> progress events optional. Specifications add new features over time,
> and it doesn't make sense to require all new features to be optional.
> Nothing about progress events makes them a special case for this.

Agreed.

> Other comments:
>
> - Conformance section -- the spec should define conformance classes.
> I suggest "conforming implementation" and a conformance class for
> specs that define use of progress events, much like the conformance
> classes for the access-control spec.

Yes, agree we should do something like this. @@To do

> - "A progress event occurs when the user agent makes progress in some
> network operation" -- perhaps this should be "data transfer
> operation", as it might not necessarily be over a network.

Yes, made this change.

> - "User agents may dispatch one or more ProgressEvent of type
> progress while a network operation is taking place." -- per my
> earlier use cases document, I'd like to suggest requiring dispatching
> at least one as the size is known (or definitely known to be unknown).

Can you definitively know that the size is unknown? If the size is known to be zero, why have to fire the extra event? When the size is known, that knowledge is not necessarily accurate.

For these reasons, but also because I am still a minimalist, I am not sure we should do this - so haven't yet made the change. What do others think?

> - "These events must not bubble, and must be cancelable." -- I
> suggest making these not cancelable, since there's no default action
> to prevent.

When discussed at the face to face - http://lists.w3.org/Archives/Public/public-webapi/2007Feb/att-0023/f2f5.html#item06 - the reason to make it cancelable was that while there is no defined default action, there might be a user agent default widget, and an application author may wish to cancel that and provide their own widget. Is there a better way to enable this than making the event cancelable?

> - "readonly boolean lengthComputable" -- I suggest renaming this to
> "totalKnown", to avoid arbitrary inconsistency with the name of the
> "total" attribute, and because "known" is more accurate than
> "computable".

it began that way for compatibility with existing implementations, so I am waiting to hear what others say.

cheers

Chaals

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

Reply | Threaded
Open this post in threaded view
|

Re: New Progress Events spec

Bjoern Hoehrmann
In reply to this post by Charles McCathieNevile-2

* Charles McCathieNevile wrote:
>To+: Bjoern. Bjoern, could you please review this specification
>for compatibility with DOM3 events?

I've already made a number of comments, assuming the issues I pointed
out have been fixed, I do not currently have anything to add, but will
follow the draft as it progresses and comment as needed.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

Re: New Progress Events spec

Maciej Stachowiak
In reply to this post by Charles McCathieNevile-2


On Mar 6, 2007, at 10:39 PM, Charles McCathieNevile wrote:

> On Wed, 07 Mar 2007 14:13:58 +1100, Maciej Stachowiak  
> <[hidden email]> wrote:
>
>> - "User agents may dispatch one or more ProgressEvent of type
>> progress while a network operation is taking place." -- per my
>> earlier use cases document, I'd like to suggest requiring dispatching
>> at least one as the size is known (or definitely known to be  
>> unknown).
>
> Can you definitively know that the size is unknown?

With http, yes, you can tell that you won't know it until you get all  
the data. Probably similar for other protocols.

> If the size is known to be zero, why have to fire the extra event?

Actually, I think it's fine not to fire it for size 0 (or in general  
if it's ready to fire when the load is already complete, but that  
might water down the conformance requirement to meaninglessness).

> When the size is known, that knowledge is not necessarily accurate.

Can you cite an example?

> For these reasons, but also because I am still a minimalist, I am  
> not sure we should do this - so haven't yet made the change. What  
> do others think?
>
>> - "These events must not bubble, and must be cancelable." -- I
>> suggest making these not cancelable, since there's no default action
>> to prevent.
>
> When discussed at the face to face - http://lists.w3.org/Archives/ 
> Public/public-webapi/2007Feb/att-0023/f2f5.html#item06 - the reason  
> to make it cancelable was that while there is no defined default  
> action, there might be a user agent default widget, and an  
> application author may wish to cancel that and provide their own  
> widget. Is there a better way to enable this than making the event  
> cancelable?

I don't know of any user agent that has per-resource progress UI that  
it would make sense to cancel. Most browsers have a single progress  
bar that covers loading of all resources during initial page load, I  
don't think there's any sensible way to interpret cancelling progress  
events for only a single resource for purposes of the overall  
progress bar. In Safari, we also show size loaded so far per resource  
and whether it is complete in a separate Activity window, I also do  
not think it makes sense to cancel this.

Can whoever suggested this be more specific about what they had in mind?


>> - "readonly boolean lengthComputable" -- I suggest renaming this to
>> "totalKnown", to avoid arbitrary inconsistency with the name of the
>> "total" attribute, and because "known" is more accurate than
>> "computable".
>
> it began that way for compatibility with existing implementations,  
> so I am waiting to hear what others say.

What implementations have "lengthComputable" and "total"? Are these  
SVG 1.2 implementations? Since all the event names are changing, I'm  
not sure this is relevant. But the name is not the world's most  
important thing.

Regards,
Maciej




Reply | Threaded
Open this post in threaded view
|

Re: New Progress Events spec

Charles McCathieNevile-2
In reply to this post by Bjoern Hoehrmann

On Wed, 07 Mar 2007 17:45:25 +1100, Bjoern Hoehrmann <[hidden email]> wrote:

>
> * Charles McCathieNevile wrote:
>>To+: Bjoern. Bjoern, could you please review this specification
>>for compatibility with DOM3 events?
>
> I've already made a number of comments, assuming the issues I pointed
> out have been fixed, I do not currently have anything to add, but will
> follow the draft as it progresses and comment as needed.

Thank you.

Cheers

Chaals

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

Reply | Threaded
Open this post in threaded view
|

Re: New Progress Events spec

Anne van Kesteren-2
In reply to this post by Maciej Stachowiak

On Wed, 07 Mar 2007 08:38:41 +0100, Maciej Stachowiak <[hidden email]>  
wrote:
>> When the size is known, that knowledge is not necessarily accurate.
>
> Can you cite an example?

   Content-Length: 2
   Content-Type: text/plain; charset="us-ascii"

   xxxx

Would be one I suppose...


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Reply | Threaded
Open this post in threaded view
|

Re: New Progress Events spec

Maciej Stachowiak


On Mar 7, 2007, at 12:45 AM, Anne van Kesteren wrote:

> On Wed, 07 Mar 2007 08:38:41 +0100, Maciej Stachowiak  
> <[hidden email]> wrote:
>>> When the size is known, that knowledge is not necessarily accurate.
>>
>> Can you cite an example?
>
>   Content-Length: 2
>   Content-Type: text/plain; charset="us-ascii"
>
>   xxxx
>
> Would be one I suppose...

This is not a valid http message. The http spec seems to want you to  
treat this this is length 2 entity-body, but it's not very clear (it  
also says user-agents MUST warn the user in this case, but I don't  
think anyone does that). Safari 2 and Opera 9 appear to respect this,  
although Firefox 2 doesn't. I don't know if that's a bug or a  
deliberate compatibility feature.

Regards,
Maciej


Reply | Threaded
Open this post in threaded view
|

Re: New Progress Events spec

Maciej Stachowiak
In reply to this post by Charles McCathieNevile-2


On Mar 6, 2007, at 10:39 PM, Charles McCathieNevile wrote:

> On Wed, 07 Mar 2007 14:13:58 +1100, Maciej Stachowiak  
> <[hidden email]> wrote:
>
>>
>> On Mar 6, 2007, at 6:02 PM, Charles McCathieNevile wrote:
>>
>>>
>>> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/
>>> Progress.html?rev=1.8
>>>
>>> I would appreciate review, and in particular propose to publish
>>> this spec as a First Public Working Draft more or less in its
>>> current shape.
>>
>> I think it's fine for FPWD, other comments notwithstanding.
>
> Thanks, and thanks for the comments. I have made a new draft with  
> some changes incorporated as discussed below...

Comments on new draft:

- Style-wise, it might be clearer to introduce the ProgressEvent  
interface first, and then describe the various events

- Italicizing the event names is confusing, especially since it  
clashes. A monospace font and/or a link to the definition would be  
more appropriate.

- It would be nice to have a table or the like of the event types and  
their meaning, like the current DOM 3 Events draft has for the event  
modules it defines. This will make it more clear what the spec is  
actually defining.

- "begin" might not be the best name for the event at the start of  
loading, since all sorts of processes can begin. For example, SMIL  
1.0 has an event named "begin" that means something completely  
different, and SMIL 2.0 has the uncomfortably similar "beginEvent".  
May I suggest using "loadstart", as I originally proposed?

- "These events are in the null namespace. Initialisation methods are  
provided in both namespaced and un-namespaced versions for use as  
appropriate. This specification does not recommend one over the other."

- "User agents must dispatch a ProgressEvent of type load" -- I  
suggest instead of language like this, the spec say things like "user  
agents must dispatch a load event", the fact that the load event  
should implement the ProgressEvent interface should be specified for  
the event type. Similarly for the other events.

- Spec should consistently use "dispatch" rather than "fire".

This seems to be confusing the ProgressEvent interface, which  
provides both kinds of init methods and doesn't recommend one or the  
other, with the events defined by the spec ("these events"), which  
definitely use the null namespace, and the spec shouldn't leave  
options both ways.

Regards,
Maciej




Reply | Threaded
Open this post in threaded view
|

Re: New Progress Events spec

Ian Hickson
In reply to this post by Charles McCathieNevile-2

On Wed, 7 Mar 2007, Charles McCathieNevile wrote:

> >
> > I think the event 'progressError' should be 'error' for backwards
> > compatibility.
> >
> > I think the event 'progressCanceled' should be 'abort' for backwards
> > compatibility.
> >
> > I think the event 'progressComplete' should be 'load' for backwards
> > compatibility'.
>
> All these are fine by me.
>
> > The spec doesn't say how to decide whether to fire 'error' or 'abort'.
> >
> > The spec implies that 'error' and 'abort' are not mutually exclusive
> > with 'load'.
>
> The spec doesn't mention 'error' or 'abort', but the ways to arrive at
> various end states are indeed not clearly distinguished.

Sorry, s/error/progressError/, s/abort/progressCanceled/, and
s/load/progressComplete/ in the above comments; I was assuming the earlier
changes were accepted by the time I got to that comment. :-)


> > The spec says that the events must be cancelable but does not define
> > their default action.
>
> Right. Do you have a suggestion for a default action? Is there a reason
> we need one for everybody to implement?

If there isn't one, it should just say so.


> > The following requirement both abuses RFC2119 terminology and makes no
> > sense from a conformance point of view: "This method may only be
> > called before the progress event has been dispatched via the
> > dispatchEvent method, though it may be called multiple times during
> > that phase if necessary."
>
> Could you explain what you mean by "makes no sense"?

"may only" is not RFC2119-compatible grammar.

It also doesn't really make much sense to give conformance requirments on
when a method call can be called. It's not formally checkable, and we have
to define what happens when the requirement is violated anyway.

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

Reply | Threaded
Open this post in threaded view
|

Re: New Progress Events spec

Charles McCathieNevile-2

On Thu, 08 Mar 2007 06:17:14 +1100, Ian Hickson <[hidden email]> wrote:

> On Wed, 7 Mar 2007, Charles McCathieNevile wrote:

>> > I think the event 'progressError' should be 'error' for backwards
>> > compatibility.
...
>> The spec doesn't mention 'error' or 'abort', but the ways to arrive at
>> various end states are indeed not clearly distinguished.
>
> Sorry, s/error/progressError/, s/abort/progressCanceled/, and
> s/load/progressComplete/ in the above comments; I was assuming the earlier
> changes were accepted by the time I got to that comment. :-)

OK. I'll stop being small-minded ;) (Those changes are in the new draft, BTW).

>> > The spec says that the events must be cancelable but does not define
>> > their default action.
>>
>> Right. Do you have a suggestion for a default action? Is there a reason
>> we need one for everybody to implement?
>
> If there isn't one, it should just say so.

Right, that works for me.

>> > The following requirement both abuses RFC2119 terminology and makes no
>> > sense from a conformance point of view: "This method may only be
>> > called before the progress event has been dispatched via the
>> > dispatchEvent method, though it may be called multiple times during
>> > that phase if necessary."
>>
>> Could you explain what you mean by "makes no sense"?
>
> "may only" is not RFC2119-compatible grammar.

Yep.

> It also doesn't really make much sense to give conformance requirments on
> when a method call can be called. It's not formally checkable, and we have
> to define what happens when the requirement is violated anyway.

So I am not sure what the use case is for the restriction, actually. I will try to find out, because I don't see what it achieves and will otherwise remove it.

cheers

Chaals


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

Reply | Threaded
Open this post in threaded view
|

Re: New Progress Events spec

Al Gilman
In reply to this post by Charles McCathieNevile-2

At 1:02 PM +1100 7 03 2007, Charles McCathieNevile wrote:
>http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.8
>
>I would appreciate review, and in particular propose to publish this
>spec as a First Public Working Draft more or less in its current
>shape.
>
>All other comments and criticisms are of course appreciated...

Have you had a chance to compare notes with the people doing SCXML in
Voice Browser WG?

I had an interesting discussion with them about how to identify the
events returning from a detached, asynchronous process.

<quote
cite="http://www.w3.org/TR/2007/WD-scxml-20070221/#Invoke">

When the <invoke> element is executed, the platform MUST start a new
logical instance of the external service specified in "targettype"
and pass it the data specified by "src", "srcexpr", <content>, or
<param>. The service instance MAY be local or remote. In addition to
the explicit arguments, the platform MUST pass a unique id to the
external service . The external service MUST include the same id in
all events that it returns to the invoking machine. (Syntax TBD.)

</quote>

Al

>
>cheers
>
>Chaals
>
>--
>   Charles McCathieNevile, Opera Software: Standards Group
>   hablo español  -  je parle français  -  jeg lærer norsk
>[hidden email]          Try Opera 9.1     http://opera.com


Reply | Threaded
Open this post in threaded view
|

RE: New Progress Events spec

Gottfried Zimmermann
In reply to this post by Charles McCathieNevile-2

Charles,

a couple of comments:

(1) I think it would be useful to have (optional) information about time
included in the event, such as:
* elapsedTime
* estimatedTotalTime
* estimatedRemainingTime

It seems that the originator of the ProgressEvent would have a better chance
to do a good estimation than the receiver, since it has probably more
knowledge about bandwidth, other traffic, etc.

(2) The current spec should not be called "ProgressEvent", but rather
"DownloadProgressEvent".  Its scope is restricted to a narrow use case.  

However, have you thought about widening the scope, to include things like:
* Application timeouts (including the ability of AT to extend timeout
durations)
* Processing that requires a long time, e.g. compiling
* Whole transactions (not just downloading data)

Gottfried


> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Charles McCathieNevile
> Sent: Wednesday, March 07, 2007 3:03 AM
> To: web API
> Cc: WAI PF public
> Subject: New Progress Events spec
>
>
>
> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progr
> ess.html?rev=1.8
>
> I would appreciate review, and in particular propose to
> publish this spec as a First Public Working Draft more or
> less in its current shape.
>
> All other comments and criticisms are of course appreciated...
>
> cheers
>
> Chaals
>
> --
>   Charles McCathieNevile, Opera Software: Standards Group
>   hablo español  -  je parle français  -  jeg lærer norsk
> [hidden email]          Try Opera 9.1     http://opera.com
>


Reply | Threaded
Open this post in threaded view
|

Re: New Progress Events spec

Charles McCathieNevile-2

On Wed, 14 Mar 2007 07:13:22 -0700, Gottfried Zimmermann <[hidden email]> wrote:

>
> Charles,
>
> a couple of comments:
>
> (1) I think it would be useful to have (optional) information about time
> included in the event, such as:
> * elapsedTime
> * estimatedTotalTime
> * estimatedRemainingTime
>
> It seems that the originator of the ProgressEvent would have a better chance
> to do a good estimation than the receiver, since it has probably more
> knowledge about bandwidth, other traffic, etc.

Estimating the total or remaining time is in general (e.g. for network operations, but also for compilation and similar extension use cases) just a guess based on what has happened so far, and it seems to make more sense to me to leave that to the consumer of the progress events.

Do we need to explicitly attach time information to the progress events, or is it already available? (I need to sleep on this, or defer to someone who has the answer at their fingertips)

> (2) The current spec should not be called "ProgressEvent", but rather
> "DownloadProgressEvent".  Its scope is restricted to a narrow use case.

There is no reason it cannot be used for an upload, such as an HTTP PUT operation. Handling two-phase operations like HTTP POST is noted as a current issue (see below) with a proposed resolution.

> However, have you thought about widening the scope, to include things like:
> * Application timeouts (including the ability of AT to extend timeout
> durations)

Can you please expand on the use case for this and how it would work?

> * Processing that requires a long time, e.g. compiling

This has been considered. In principle I believe there is nothing that prevents such a process from being a source of progress events. The names of some of the events are chosen for backwards compatibility with existing operations. If it were clear how to measure the progress of some event other than in terms of byte transfers it would be worth considering how to do this, but I have not seen a clear proposal yet.

> * Whole transactions (not just downloading data)

There is an issue highlighted by the specific case of HTTP POST, where there is both an upload and a download component. Our proposal is to require that an operation which has progress in two phases provide two event targets for progress events. As far as I know, it is not a priori possible to know anything about the progress in advance of the actual operation, so there is not much point trying to anticipate that.

cheers

Chaals

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

Reply | Threaded
Open this post in threaded view
|

Re: New Progress Events spec

Cameron McCormack-4

Charles McCathieNevile:
> Estimating the total or remaining time is in general (e.g. for network
> operations, but also for compilation and similar extension use cases)
> just a guess based on what has happened so far, and it seems to make
> more sense to me to leave that to the consumer of the progress events.
>
> Do we need to explicitly attach time information to the progress
> events, or is it already available? (I need to sleep on this, or defer
> to someone who has the answer at their fingertips)

The Event interface has a timeStamp attribute:

  timeStamp of type DOMTimeStamp, readonly
    Used to specify the time at which the event was created in
    milliseconds relative to 1970-01-01T00:00:00Z. Due to the fact
    that some systems may not provide this information the value of
    timeStamp may be not available for all events. When not available,
    the value is 0.
  —http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-Event-timeStamp

So I guess that is a “usually available”.

--
Cameron McCormack, http://mcc.id.au/
        xmpp:[hidden email]  ▪  ICQ 26955922  ▪  MSN [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: New Progress Events spec

Gottfried Zimmermann
In reply to this post by Charles McCathieNevile-2

> > However, have you thought about widening the scope, to
> include things
> > like:
> > * Application timeouts (including the ability of AT to
> extend timeout
> > durations)
>
> Can you please expand on the use case for this and how it would work?

A typical use case would be an online banking application that warns the
user 2 minutes before the session will time out (for security reasons).
Currently my online bank does this through opening a new window where the
user can opt for extending the session and stopping the current timeout
counter.

If there was an event for this, the user agent could act on it on behalf of
the user.  For example, it could extend the session for a user if the user
is still busy filling out the form.  This would be particularly important
for users with disabilities that sometimes require much longer time for
filling out forms, and would even miss to answer the timeout warning in
time.

But maybe that should even be a new event called "TimeoutEvent"?

Thanks,
Gottfried


> -----Original Message-----
> From: Charles McCathieNevile [mailto:[hidden email]]
> Sent: Saturday, March 17, 2007 12:25 AM
> To: Gottfried Zimmermann; 'web API'
> Cc: 'WAI PF public'
> Subject: Re: New Progress Events spec
>
>
> On Wed, 14 Mar 2007 07:13:22 -0700, Gottfried Zimmermann
> <[hidden email]> wrote:
>
> >
> > Charles,
> >
> > a couple of comments:
> >
> > (1) I think it would be useful to have (optional) information about
> > time included in the event, such as:
> > * elapsedTime
> > * estimatedTotalTime
> > * estimatedRemainingTime
> >
> > It seems that the originator of the ProgressEvent would
> have a better
> > chance to do a good estimation than the receiver, since it has
> > probably more knowledge about bandwidth, other traffic, etc.
>
> Estimating the total or remaining time is in general (e.g.
> for network operations, but also for compilation and similar
> extension use cases) just a guess based on what has happened
> so far, and it seems to make more sense to me to leave that
> to the consumer of the progress events.
>
> Do we need to explicitly attach time information to the
> progress events, or is it already available? (I need to sleep
> on this, or defer to someone who has the answer at their fingertips)
>
> > (2) The current spec should not be called "ProgressEvent",
> but rather
> > "DownloadProgressEvent".  Its scope is restricted to a narrow use
> > case.
>
> There is no reason it cannot be used for an upload, such as
> an HTTP PUT operation. Handling two-phase operations like
> HTTP POST is noted as a current issue (see below) with a
> proposed resolution.
>
> > However, have you thought about widening the scope, to
> include things
> > like:
> > * Application timeouts (including the ability of AT to
> extend timeout
> > durations)
>
> Can you please expand on the use case for this and how it would work?
>
> > * Processing that requires a long time, e.g. compiling
>
> This has been considered. In principle I believe there is
> nothing that prevents such a process from being a source of
> progress events. The names of some of the events are chosen
> for backwards compatibility with existing operations. If it
> were clear how to measure the progress of some event other
> than in terms of byte transfers it would be worth considering
> how to do this, but I have not seen a clear proposal yet.
>
> > * Whole transactions (not just downloading data)
>
> There is an issue highlighted by the specific case of HTTP
> POST, where there is both an upload and a download component.
> Our proposal is to require that an operation which has
> progress in two phases provide two event targets for progress
> events. As far as I know, it is not a priori possible to know
> anything about the progress in advance of the actual
> operation, so there is not much point trying to anticipate that.
>
> cheers
>
> Chaals
>
> --
>   Charles McCathieNevile, Opera Software: Standards Group
>   hablo español  -  je parle français  -  jeg lærer norsk
> [hidden email]          Try Opera 9.1     http://opera.com
>