Re: New FileAPI Draft | was Re: FileAPI feedback

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.

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

/ Jonas

Received on Tuesday, 18 August 2009 18:51:09 UTC