Jonas Sicking wrote:
On Mon, Oct 26, 2009 at 5:24 AM, Arun Ranganathan <> wrote:
The latest revision of the FileAPI editor's draft is available here:

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 -- -- 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.

* 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:


Reply via email to