W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Is BlobBuilder needed?

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 26 Oct 2011 16:14:39 -0700
Message-ID: <CA+c2ei-30o2p3qDDBmrK-6_dB079xg5QJRBDsOewTZWbX70NXg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Ojan Vafai <ojan@chromium.org>, Michael Nordman <michaeln@google.com>, Erik Arvidsson <arv@chromium.org>, Eric U <ericu@google.com>, Webapps WG <public-webapps@w3.org>
On Tue, Oct 25, 2011 at 12:57 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Tue, Oct 25, 2011 at 12:53 PM, Ojan Vafai <ojan@chromium.org> wrote:
>> The new API is smaller and simpler. Less to implement and less for web
>> developers to understand. If it can meet all our use-cases without
>> significant performance problems, then it's a win and we should do it.
>> For line-endings, you could have the Blob constructor also take an optional
>> endings argument:
>> new Blob(String|Array|Blob|ArrayBuffer data, [optional] String contentType,
>> [optional] String endings);
> I believe (or at least, I maintain) that we're trying to do
> dictionaries for this sort of thing.  Multiple optional arguments are
> *horrible* unless they are truly, actually, order-dependent such that
> you wouldn't ever specify a later one without already specifying a
> former one.

I don't have a super strong opinion. I will however note that I think
it'll be very common to specify a content-type, but much much more
rare to specify any of the other types. But maybe using the syntax

b = new Blob([foo, bar], { contentType: "text/plain" });

isn't too bad. The other properties that I could think of that we'd
want to add sometime in the future would be encoding for strings,
including endianness for utf16 strings.

/ Jonas
Received on Wednesday, 26 October 2011 23:15:36 UTC

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