W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: New FileAPI Draft | was Re: FileAPI feedback

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 17 Aug 2009 23:29:45 -0700
Message-ID: <63df84f0908172329l78048a0x875a2fcf797186a2@mail.gmail.com>
To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
Cc: arun@mozilla.com, Web Applications Working Group WG <public-webapps@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT