- From: Eric U <ericu@google.com>
- Date: Wed, 26 Oct 2011 18:08:48 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Ojan Vafai <ojan@chromium.org>, Michael Nordman <michaeln@google.com>, Erik Arvidsson <arv@chromium.org>, Webapps WG <public-webapps@w3.org>
On Wed, Oct 26, 2011 at 4:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.
That looks good to me. Endings can go in there, if we keep it.
Received on Thursday, 27 October 2011 01:09:27 UTC