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

Jonas,

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

Done.

(I was simply wrong about loadend, and citing media elements wasn't 
helpful; I've changed the spec. to show that loadend should be fired, 
and it now matches the behavior of the XHR2 editor's draft.)

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

Done.

*grumble grumble OK Jonas, in the interest of not bike shedding I've 
renamed fileData to result*

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

Fixed; this isn't harnessed to queuing ProgressEvents for dispatch anymore.

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

Fixed

(I don't feel strongly about whether to throw or not, so I changed it to 
*clamp.*  It may offer conveniences to NOT throw, but I'd like to hear 
from others).

http://dev.w3.org/2006/webapi/FileAPI/

-- A*

Received on Wednesday, 28 October 2009 23:41:40 UTC