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: Wed, 12 Aug 2009 11:27:05 -0700
Message-ID: <63df84f0908121127v1f79a948u6ba241bc8e34c11c@mail.gmail.com>
To: arun@mozilla.com
Cc: Web Applications Working Group WG <public-webapps@w3.org>
On Wed, Aug 12, 2009 at 7:42 AM, Arun Ranganathan<arun@mozilla.com> wrote:
>> What's the use-case for getAsBase64?
> It's generally hard to encode files and to send them to servers.  While Data
> URLs give developers a convenient way to work with Base64, URL length
> limitations across user agents make it pretty tough to use in practice.  And
> while we do have a getAsBinaryString now, I still think getAsBase64 is
> important because of the fact that many server environments provide ways to
> work with Base64 strings (e.g. PHP's base64_decode method, which is really
> useful along with an XHR that submits Base64 encoded strings, as well as
> Perl's decode_base64, etc.).
> It's a convenient way to encode file data and servers work with it out of
> the box .  The drawback is that it increases the data size from the original
> file.

The fact that servers can work with base64 encoded strings is not a
reason for wanting to do so.

If you want to send data to the server it seems much more desirable to
send the raw data to the server. Unless you are arguing that there are
servers out there that can't consume the raw data, but that could
consume base64 encoded data?

in other words, "because the server could consume it" is not a good
reason to send data in a particular format to the server. The reason
should be "because there's advantage X with sending in in that
format". So far I don't see an advantage "X" with base64.

/ Jonas
Received on Wednesday, 12 August 2009 18:28:10 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC