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