Re: [FileAPI] Latest Revision of Editor's Draft

Jonas Sicking wrote:
> On Mon, Oct 26, 2009 at 5:24 AM, Arun Ranganathan <arun@mozilla.com> wrote:
>   
>> The latest revision of the FileAPI editor's draft is available here:
>>
>> http://dev.w3.org/2006/webapi/FileAPI/
>>     
>
> A few comments:
>
> * loadend should fire after load/error/abort.
>   

Currently it *only* fires when error and abort events fire.  I felt that 
'load' was sufficient for successful reads into memory, while 'loadend' 
was useful for unsuccessful ones.  This differs from XHR2's definition 
of 'loadend'[1]:

"When the request has completed (either in success or failure)." [1]

When loadend was removed from media elements [2] I wished to determine 
whether it was event overkill to also fire at successful reads.   Sounds 
like you want it back for successful reads as well?


> * I'm not sure i love the name 'fileData'. Maybe 'result' or simply
> 'data' is better.
>   

I'm happy to change it to a better name, but chose 'fileData' since in 
the original version of the draft, with asynchronous callbacks [3], we 
had an interface called FileData which represented the actual file data 
(in the present and current version of the editor's draft -- 
http://dev.w3.org/2006/webapi/FileAPI/ -- FileData is called Blob) .  Of 
the two names you suggest,  do you feel strongly about one over the 
others? 

I'm not sure I love 'result' (it isn't intuitive as a response to a 
read), and 'data' is used in other contexts on the platform and so may 
be confusing.  If you feel strongly (stronger than a 'maybe' ;-) ) about 
a different name, I'm happy to change it. 

> * Whatever the name, I don't see why 'fileData' should only be
> readable while an event is being fired. That seems unnecessarily
> complicated, doesn't match XHR and seems less useful.
>   

Nothing in the present draft prohibits that -- I only left an editor's 
note as an open question.  I agree with you about the desired behavior,  
and so I'll remove the editor's note.

> * fileData should probably be null rather than the empty string during
> on error and before data is read.
>   

Done
> * The second argument to 'splice' should be called 'length' rather
> than 'offset'.
>   

Done
> * I think someone had brought up a good argument for *not* throwing
> when slice is called with start+offset > size. One of the main use
> cases for slice is to slice up a file in several chunks when sending
> with XHR. When that is done it's easy to end up with rounding errors
> resulting in a slightly to large length being requested. In this case
> it makes sense to just clamp to size rather than throwing an error.
>   

OK -- sounds like slice should NOT throw an INDEX_SIZE_ERR at all, and 
only clamp on size? 
> / Jonas
>   

Current editor's draft: http://dev.w3.org/2006/webapi/FileAPI/

[1] http://www.w3.org/TR/XMLHttpRequest2/#loadend-event
[2] 
http://dev.w3.org/cvsweb/html5/spec/Overview.html?r1=1.3290&r2=1.3291&f=h
[3] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html

Received on Tuesday, 27 October 2009 20:38:01 UTC