Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API

On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan <arun@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

Received on Thursday, 19 November 2009 00:23:45 UTC