Re: New FileAPI Draft | was Re: FileAPI feedback

On Aug 18, 2009, at 11:50 AM, Jonas Sicking wrote:

> On Tue, Aug 18, 2009 at 10:34 AM, Nikunj R.
> Mehta<nikunj.mehta@oracle.com> wrote:
>>
>> On Aug 17, 2009, at 11:29 PM, Jonas Sicking wrote:
>>
>>> On Mon, Aug 17, 2009 at 11:13 PM, Nikunj R.
>>> Mehta<nikunj.mehta@oracle.com> wrote:
>>>>
>>>> On Aug 17, 2009, at 11:08 PM, Jonas Sicking wrote:
>>>>
>>>>> On Mon, Aug 17, 2009 at 6:01 PM, Arun  
>>>>> Ranganathan<arun@mozilla.com>
>>>>> wrote:
>>>>>>
>>>>>> Nikunj R. Mehta wrote:
>>>>>>>
>>>>>>> On Aug 5, 2009, at 6:55 PM, Jonas Sicking wrote:
>>>>>>>
>>>>>>>> What's the use-case for getAsBase64?
>>>>>>>
>>>>>>>
>>>>>>> I have another use case for this. The Atom Publishing protocol  
>>>>>>> per RFC
>>>>>>> 5023 [1] accepts inline binary data represented in base 64  
>>>>>>> encoding.
>>>>>>> In
>>>>>>> order to submit binary inline content in an Atom entry to an  
>>>>>>> Atom
>>>>>>> server, it
>>>>>>> would be necessary to getAsBase64()
>>>>>>
>>>>>> Specifically, atom:entry can contain Base64-encoded content  
>>>>>> [2]; I'm
>>>>>> not
>>>>>> sure it allows *other ways* to submit inline binary content.  I  
>>>>>> suppose
>>>>>> one
>>>>>> reason to keep the ability to get data in Base64 is for legacy  
>>>>>> reasons,
>>>>>> since it happens to be a convenient way to get binary stuff  
>>>>>> into web
>>>>>> content
>>>>>> (and ultimately onto servers).  The problem is that it is not  
>>>>>> as useful
>>>>>> within webapps (at least, not as useful as binary content).   
>>>>>> Use cases
>>>>>> submitted till now involve *submitting* binary content in  
>>>>>> Base64 to
>>>>>> servers
>>>>>> that can handle Base64, but not doing anything useful with Base64
>>>>>> *within*
>>>>>> the web app (where I suspect the first thing someone might do  
>>>>>> is to
>>>>>> convert
>>>>>> it to a binary string again).
>>>>>>
>>>>>> I suppose one reason to keep it around is if:
>>>>>>
>>>>>> 1. Web app asks user to pick file
>>>>>> 2. File is picked and extracted as Base64
>>>>>> 3. Atom "container" with Base64 is submitted via XHR using the  
>>>>>> Atom
>>>>>> Publishing Protocol [1].
>>>>>>
>>>>>> I'm willing to keep a way to get data as Base64 around for such  
>>>>>> cases.
>>>>>
>>>>> There's lots of formats used on the web, I don't think it makes  
>>>>> sense
>>>>> to add file-getters for all of them. JSON has gotten a lot of
>>>>> attention lately, does this mean we should add a getter that  
>>>>> return a
>>>>> js-style escaped string?
>>>>>
>>>>> We have getAsBinaryString, using that you can get the raw data and
>>>>> then base64 or escape encode it, or convert it to whatever  
>>>>> format you
>>>>> want.
>>>>>
>>>>> / Jonas
>>>>
>>>>
>>>> An IETF working group has published standards track proposals for a
>>>> format
>>>> and a protocol that uses base 64 encoding. If this is not  
>>>> sufficient
>>>> reason,
>>>> then I am sorry but you have an unduly high expectation. Let the
>>>> 'js-style
>>>> escaped string' get a similar blessing and then they can bring it  
>>>> to W3C
>>>> to
>>>> include them in browsers.
>>>
>>> Note that base64 is still supported, I just don't think adding a
>>> convenience function on the File API is warranted.
>>
>> I don't understand by what you mean that it is supported. Can you  
>> elaborate?
>
> I mean that it's possible to use the current (minus getAsBase64) API
> to send base64 encoded data to the server. You can do that in the
> following way:
>
> file.getAsBinaryString(handler);
> function handler(binaryString, err) {
>  encodedString = base64Encode(binaryString);
>  xhr.open("POST", "server.cgi");
>  xhr.send(encodedString);
> }
>
> function base64Encode(binaryString) {
>  ... code from [1] ...
> }
>
> [1] http://www.webtoolkit.info/javascript-base64.html
>
> So we don't need an explicit base64 getter on the file API in order to
> allow data to be converted into base64.

So it is possible to do encoding, except that it is not offered in the  
API. Regardless, I feel that the use of binary strings and doing the  
encoding in JavaScript is a bad approach and this spec should not move  
programmers in that direction.

I think it is probably best to provide separate readers for each  
different format - binary, encoded binary, and text. I feel that  
Michael's proposal is better than the current editor's draft in that  
it clearly separates the file from its readers and the data.

>
>>> If we did,
>>> shouldn't we also add a base64 encoding function on XMLHttpRequest?
>>> the SQL (or other database) API? On postMessage?
>>>
>>> And then multiply that by the number of IETF blessed encodings? That
>>> adds up to a lot of API.
>>>
>>> If base64 is important enough that we should have built-in support  
>>> for
>>> it, it seems better to support that separated from the File API so
>>> that it can be used with other data sources than files.
>>
>> Perhaps you are suggesting that a file reader should support taking  
>> encoding
>> as an option so that the reader can obtain whatever format it is  
>> interested
>> in as long as the browser supports it. That would keep the API  
>> clean. If so,
>> I would suggest that base64 be a required encoding.
>
> No, I'm suggesting that we decouple APIs that do encoding/decoding,
> from APIs that deal with specific data sources. Otherwise we need to
> add encoding/decoding APIs on each data source. So if we consider
> base64 encoding to be critical, lets add a native API to implement the
> base64Encode function in the example above.
>

This I agree will be a step in the right direction. It seems you are  
suggesting something similar to Java's InputStreamReader so that the  
bytes can be converted to characters using a controlled decoding  
mechanism.

> / Jonas
>

Nikunj
http://o-micron.blogspot.com

Received on Tuesday, 18 August 2009 19:07:59 UTC