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

Re: Is BlobBuilder needed?

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 24 Oct 2011 19:23:38 -0700
Message-ID: <CA+c2ei_QgkV7PAUapfbRH0BJ0Nhs_Ltnh5qXAvOYgaZWVotEKg@mail.gmail.com>
To: Ojan Vafai <ojan@chromium.org>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Eric U <ericu@google.com>, Webapps WG <public-webapps@w3.org>
On Mon, Oct 24, 2011 at 7:11 PM, Ojan Vafai <ojan@chromium.org> wrote:
> On Mon, Oct 24, 2011 at 6:40 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Mon, Oct 24, 2011 at 4:46 PM, Tab Atkins Jr. <jackalmage@gmail.com>
>> wrote:
>> > On Mon, Oct 24, 2011 at 4:33 PM, Eric U <ericu@google.com> wrote:
>> >> The only things that this lacks that BlobBuilder has are the endings
>> >> parameter for '\n' conversion in text and the content type.  The
>> >> varargs constructor makes it awkward to pass in flags of any
>> >> sort...any thoughts on how to do that cleanly?
>> >
>> > Easy.  The destructuring stuff proposed for ES lets you easily say
>> > things like:
>> >
>> > function(blobparts..., keywordargs) {
>> >  // blobparts is an array of all but the last arg
>> >  // keywordargs is the last arg
>> > }
>> >
>> > or even:
>> >
>> > function(blobparts..., {contenttype, lineendings}) {
>> >  // blobparts is an array of all but the last arg
>> >  // contenttype and lineendings are pulled from the
>> >  // last arg, if it's an object with those properties
>> > }
>>
>> The problem is that if the caller has an array, because this is a
>> constructor, this will get *very* awkward to do until ES6 is actually
>> implemented.
>
> We should pressure ecmascript to stabilize this part of ES6 early so that we
> can implement it. That way we can start designing the APIs we want now
> instead of almost the APIs we want. That said, I'm not opposed to the array
> argument for now. We can always add the destructured version in addition
> later.

That's the route I would prefer to go yeah.

> On the topic of getting rid of BlobBuilder, do you have thoughts on losing
> the ability to back it by an on-disk file?

I'm not sure I understand the problem. A Blob can also be backed by a
on-disk file.

Could you elaborate?

>> You can't simply do:
>>
>> new Blob.apply(blobarray.concat("text/plain"));
>>
>> I *think* this is what you'd have to do in a ES5 compliant engine:
>>
>> new Blob.bind([null].concat(blobarray, "text/plain));
>>
>> In ES3 I don't even think that there's a way to do it. Though that
>> might not matter assuming everyone gets .bind correctly implemented
>> before they implement |new Blob|.
>>
>> I don't think the complexity is worth it for a dubious gain. I.e. it's
>> not entirely clear to me that the following:
>>
>> new Blob(blob1, blob2, mybuffer, blob3, "somestring", "text/plain");
>
>
> Could we make the first argument be the contenttype? That makes the vararg
> version work better. As it is, "text/plain" could, theoretically be part of
> the content. I guess that's an argument for only doing the array version.
> Then the contenttype could come second and be optional. As I said, I don't
> feel strongly about this.

That only changes

new Blob.bind([null].concat(blobarray, "text/plain"));

to

new Blob.bind([null].concat("text/plain", blobarray));

So I'm not sure it's a lot better :-)

/ Jonas
Received on Tuesday, 25 October 2011 02:24:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT