Re: New Progress Events spec

On Wed, 07 Mar 2007 14:13:58 +1100, Maciej Stachowiak <mjs@apple.com> 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
chaals@opera.com          Try Opera 9.1     http://opera.com

Received on Wednesday, 7 March 2007 06:39:24 UTC