On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan <a...@mozilla.com> wrote:

Greetings Marcin,

Thanks for the thoughtful feedback.  My comments below:

In my opinion some part of the design from ProgressEvents is taken over in FileReader API too directly.
Specifically the event names are the same as within the ProgressEvents,
...

What's in a name? [Floral poetry reference elided :-) ].

You are right to point out that there's some inconsistency in the naming convention. This discussion came up with the discussion of readyState [1] state name changes, when READING was considered as a potential readyState, were it not for consistency with the progress events in question (loadstart, load, loadend... ). We elected to stick to LOADING to match the names of existing progress events with 'load' in them.
...


To date, you'll note that progress event nomenclature reflects "loading" or "reading" operations, since there are very few "write" metaphors on the web that have affiliated events bound to them.

Actually, this is a false etiology. The naming conventions are based on what people were already implementing (as Robin says, it is often easier to extend the definition than change the term, as linguistics shows us over a far longer history than the Web).

If the design of the FileWriter is similar to the design of the FileReader (which is something we're currently working on), then I think your names make sense.

I don't actually. We have dumb names, because those are the terms we keep using... and the ones people are used to.

Then, the ProgressEvents spec could act as a design pattern definition for lengthy, asynchronous operations. To make it happen, the names of the events there could be changed to be generic:


I think that just as the names 'load*' were chosen for generic data transfer events (either networked or within a document), and are used within documents loaded in the DOM, XHR, and FileReader, we'll need reusable 'write*' events....

Actually, if the argument to keep the names makes sense, then it makes sense, so there is not much point in trying to separate out a bunch of things with a new name. Experience has shown it doesn't usually work anyway.

loadstart -> start
progress
stalled
suspend
error

I like the proposal to have a section specific to data transfer and loading, but am wary of splitting specs. Input and feedback from the author of the ProgressEvents specification would be welcome here.

The "author" is the Working Group - and ergo all the members. I'm just the editor.

cheers

Chaals

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

Reply via email to