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

Re: Is BlobBuilder needed?

From: Ojan Vafai <ojan@chromium.org>
Date: Mon, 24 Oct 2011 19:11:29 -0700
Message-ID: <CANMdWTsd7hj70tOpYdDE2Vuya8RGWzK-zY_EwC+-F7KCvCQvQQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Eric U <ericu@google.com>, Webapps WG <public-webapps@w3.org>
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

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

> 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.

> is significantly better than
> new Blob([blob1, blob2, mybuffer, blob3, "somestring"], "text/plain");

> / Jonas
Received on Tuesday, 25 October 2011 02:12:15 UTC

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