Re: New FileAPI Draft | was Re: FileAPI feedback

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

/ Jonas

Received on Tuesday, 18 August 2009 06:30:44 UTC