W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

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

From: Arun Ranganathan <arun@mozilla.com>
Date: Wed, 28 Oct 2009 16:40:58 -0700
Message-ID: <4AE8D68A.5000303@mozilla.com>
To: Jonas Sicking <jonas@sicking.cc>, Web Applications Working Group WG <public-webapps@w3.org>

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


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


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


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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC