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

On Tue, Oct 27, 2009 at 11:58 AM, Arun Ranganathan <arun@mozilla.com> wrote:
> 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?

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

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

Received on Tuesday, 27 October 2009 21:08:38 UTC