On Aug 17, 2009, at 11:29 PM, Jonas Sicking wrote:
On Mon, Aug 17, 2009 at 11:13 PM, Nikunj R.
Mehta<nikunj.me...@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<a...@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
