On Aug 18, 2009, at 11:50 AM, Jonas Sicking wrote:
On Tue, Aug 18, 2009 at 10:34 AM, Nikunj R.
Mehta<nikunj.me...@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.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?
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.
So it is possible to do encoding, except that it is not offered in the
API. Regardless, I feel that the use of binary strings and doing the
encoding in JavaScript is a bad approach and this spec should not move
programmers in that direction.
I think it is probably best to provide separate readers for each
different format - binary, encoded binary, and text. I feel that
Michael's proposal is better than the current editor's draft in that
it clearly separates the file from its readers and the data.
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.
This I agree will be a step in the right direction. It seems you are
suggesting something similar to Java's InputStreamReader so that the
bytes can be converted to characters using a controlled decoding
mechanism.
/ Jonas
Nikunj
http://o-micron.blogspot.com
