Jonas Sicking wrote:
On Mon, Oct 26, 2009 at 5:24 AM, Arun Ranganathan <a...@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
