- From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Date: Tue, 18 Aug 2009 10:34:29 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: arun@mozilla.com, Web Applications Working Group WG <public-webapps@w3.org>
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? > 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. Nikunj http://o-micron.blogspot.com
Received on Tuesday, 18 August 2009 17:37:09 UTC