W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

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

From: Arun Ranganathan <arun@mozilla.com>
Date: Tue, 27 Oct 2009 11:58:14 -0700
Message-ID: <4AE742C6.6050603@mozilla.com>
To: Web Applications Working Group WG <public-webapps@w3.org>
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 

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.

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

> * 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
[3] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Received on Tuesday, 27 October 2009 20:38:01 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC