Re: New FileAPI Draft | was Re: FileAPI feedback

Jonas Sicking wrote:
> A few comments:
>
> Need to specify that all getAsX functions call the callback
> *asynchronously*. Also need to integrate this with the HTML5 event
> loop.
>   
Done.
> getAsBinary should be called getAsBinaryString so that once we have a
> BinaryArray or some such we can add a getAsBinary that truly returns
> binary data.
>
>   
Done
> Need to specify the actual encoding for getAsBinary, i.e. that each
> character holds one byte, valued between 0-255.
>
>   
Done, though this generated an editor's note.
> Obviously the filedata scheme needs to be defined in greater detail.
>
>   
Done -- comments welcome.
> What's the use-case for getAsBase64?
>
>   
It's generally hard to encode files and to send them to servers.  While 
Data URLs give developers a convenient way to work with Base64, URL 
length limitations across user agents make it pretty tough to use in 
practice.  And while we do have a getAsBinaryString now, I still think 
getAsBase64 is important because of the fact that many server 
environments provide ways to work with Base64 strings (e.g. PHP's 
base64_decode method, which is really useful along with an XHR that 
submits Base64 encoded strings, as well as Perl's decode_base64, etc.). 

It's a convenient way to encode file data and servers work with it out 
of the box .  The drawback is that it increases the data size from the 
original file.

Do you disagree with why I think it is useful?

> splice should synchronously return a new FileData object. No need for
> asynchronous callback since no IO occurs.
>
>   
Done, though I used Anne's suggestion to make it an attribute.
> getAsBinaryString could take two optional |start| and |length|
> arguments to avoid having to use splice to read parts of a file.
>
>   
Currently, slice allows us to create new byte-ranged FileData objects.  
Is that not sufficient?  The advantage of using slice, and then calling 
any accessor you want (including getAsBinaryString) is that you can do 
much more than with just an arbitrary byte-ranged binary string.

-- A*

Received on Wednesday, 12 August 2009 14:53:32 UTC