On Tue, Oct 27, 2009 at 11:58 AM, Arun Ranganathan <a...@mozilla.com> wrote: > 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': > > "When the request has completed (either in success or failure)."  > > When loadend was removed from media elements  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?
But the reason why loadend *and load* was removed from video do not apply here. The reason there was that they never guarentee that the whole video is downloaded such that it can be accessed without further need for network access. Additionally we should follow the intent of the Progress Events spec. >> * 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 , 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) . But that FileData represented the actual data in the file. .fileData can be a data-uri or a string of text, neither of which is exactly the data in the file. > 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. I don't feel that strongly no. But i think 'result' the the most correct name that I can think of. >> * 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. Ah, ok. There was also some confusing wording in the definition of the attribute: "On getting, if progress events are queued for dispatch while processing the readAsText read method, this attibute SHOULD return partial file data in the format specified by the encoding determination)" However it should contain the data read so far even if there currently aren't any progress events queued for dispatch. I.e. if a progress event was just dispatched and no more data has been read so far, then .fileData should still contain the same value as when the last progress event was dispatched. >> * 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? Yeah, I think so. Except if the 'start' attribute is bigger then size. Though possibly we could even then clamp to a zero-sized Blob. I don't really feel strongly. / Jonas