Re: Is BlobBuilder needed?
On Tue, Nov 15, 2011 at 5:41 AM, Rich Tibbett wrote:
> Jonas Sicking wrote:
>>
>> Hi everyone,
>>
>> It was pointed out to me on twitter that BlobBuilder can be replaced
>> with simply making Blob constructable. I.e. the following code:
>>
>> var bb = new BlobBuilder();
>> bb.append(blob1);
>> bb.append(blob2);
>> bb.append("some string");
>> bb.append(myArrayBuffer);
>> var b = bb.getBlob();
>>
>> would become
>>
>> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>>
>> or look at it another way:
>>
>> var x = new BlobBuilder();
>> becomes
>> var x = [];
>>
>> x.append(y);
>> becomes
>> x.push(y);
>>
>> var b = x.getBlob();
>> becomes
>> var b = new Blob(x);
>>
>> So at worst there is a one-to-one mapping in code required to simply
>> have |new Blob|. At best it requires much fewer lines if the page has
>> several parts available at once.
>>
>> And we'd save a whole class since Blobs already exist.
>
> Following the previous discussion (which seemed to raise no major
> objections) can we expect to see this in the File API spec sometime soon
> (assuming that spec is the right home for this)?
>
> This will require a coordinated edit to coincide with the removal of
> BlobBuilder from the File Writer API, right?
It need not be all that coordinated. I can take it out [well...mark
it deprecated, pending implementation changes] any time after the Blob
constructor goes into the File API.
> Thanks,
>
> Rich
>
>>
>> / Jonas
>
Re: Is BlobBuilder needed?
On Tue, Nov 15, 2011 at 11:04 AM, Kyle Huey wrote: > I think we decided that we're going to remove getFile. See > https://bugzilla.mozilla.org/show_bug.cgi?id=669437#c7 and later. > FWIW, although I won't argue strongly for it here (we can always come back to it), I don't think there are any strong arguments against being able to create Files in there. You don't need a real file on a filesystem in order to expose file metadata in File (it's just an interface), and having objects with the File interface always backed by a filesystem file doesn't seem like a very meaningful distinction. -- Glenn Maynard
Re: Is BlobBuilder needed?
On Tue, Nov 15, 2011 at 10:55 AM, Glenn Maynard wrote:
> On Mon, Oct 24, 2011 at 6:52 PM, Jonas Sicking wrote:
>
>> It was pointed out to me on twitter that BlobBuilder can be replaced
>> with simply making Blob constructable. I.e. the following code:
>>
>
> I noticed this at
> https://developer.mozilla.org/en/Firefox_8_for_developers:
>
> "BlobBuilder now has a getFile() method that returns the content of the
> blob as a file."
>
> This suggests a File constructor as well, eg. b = new File([foo, bar], {
> name: "file.jpg" });.
>
> (Of course, the only difference is that the created object has the File
> interface, with an attached filename. It would make no difference to how
> the data is stored, which isn't actually tied to the interface.)
>
I think we decided that we're going to remove getFile. See
https://bugzilla.mozilla.org/show_bug.cgi?id=669437#c7 and later.
- Kyle
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 6:52 PM, Jonas Sicking wrote:
> It was pointed out to me on twitter that BlobBuilder can be replaced
> with simply making Blob constructable. I.e. the following code:
>
I noticed this at https://developer.mozilla.org/en/Firefox_8_for_developers:
"BlobBuilder now has a getFile() method that returns the content of the
blob as a file."
This suggests a File constructor as well, eg. b = new File([foo, bar], {
name: "file.jpg" });.
(Of course, the only difference is that the created object has the File
interface, with an attached filename. It would make no difference to how
the data is stored, which isn't actually tied to the interface.)
--
Glenn Maynard
Re: Is BlobBuilder needed?
Jonas Sicking wrote:
Hi everyone,
It was pointed out to me on twitter that BlobBuilder can be replaced
with simply making Blob constructable. I.e. the following code:
var bb = new BlobBuilder();
bb.append(blob1);
bb.append(blob2);
bb.append("some string");
bb.append(myArrayBuffer);
var b = bb.getBlob();
would become
b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
or look at it another way:
var x = new BlobBuilder();
becomes
var x = [];
x.append(y);
becomes
x.push(y);
var b = x.getBlob();
becomes
var b = new Blob(x);
So at worst there is a one-to-one mapping in code required to simply
have |new Blob|. At best it requires much fewer lines if the page has
several parts available at once.
And we'd save a whole class since Blobs already exist.
Following the previous discussion (which seemed to raise no major
objections) can we expect to see this in the File API spec sometime soon
(assuming that spec is the right home for this)?
This will require a coordinated edit to coincide with the removal of
BlobBuilder from the File Writer API, right?
Thanks,
Rich
/ Jonas
Re: Is BlobBuilder needed?
On Thu, Oct 27, 2011 at 1:36 PM, Anne van Kesteren wrote: > On Thu, 27 Oct 2011 20:12:31 +0200, Jonas Sicking wrote: >> >> The prime use of this value is actually to act like a content type header >> when a URL created through createObjectURL(blob) is loaded. > > Doesn't it set Blob.type? It does. But that property is what determines the content-type when using createObjectURL. I suspect the property will be used a lot more that way than people actually manually inspecting blob.type and doing something with it. I'm ok with calling the options object property "type" though. It's nice that it's shorter and like you say, we're mapping it to the .type property anyway. / Jonas
Re: Is BlobBuilder needed?
On Thu, 27 Oct 2011 20:12:31 +0200, Jonas Sicking wrote: The prime use of this value is actually to act like a content type header when a URL created through createObjectURL(blob) is loaded. Doesn't it set Blob.type? -- Anne van Kesteren http://annevankesteren.nl/
Re: Is BlobBuilder needed?
On Wednesday, October 26, 2011, Anne van Kesteren wrote:
> On Thu, 27 Oct 2011 08:14:39 +0900, Jonas Sicking
wrote:
>>
>> 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.
>
> Lets call it "type" if it is not actually a Content-Type header value but
a MIME type.
The prime use of this value is actually to act like a content type header
when a URL created through createObjectURL(blob) is loaded.
/ Jonas
Re: Is BlobBuilder needed?
On Wednesday, October 26, 2011, Anne van Kesteren wrote:
> On Thu, 27 Oct 2011 08:14:39 +0900, Jonas Sicking
wrote:
>>
>> 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.
>
> Lets call it "type" if it is not actually a Content-Type header value but
a MIME type.
The prime use of this value is actually to act like a content type header
when a URL created through createObjectURL(blob) is loaded.
/ Jonas
Re: Is BlobBuilder needed?
I see. Thanks Glenn. A. TAKAYAMA On Thu, Oct 27, 2011 at 12:30 PM, Glenn Maynard wrote: > On Thu, Oct 27, 2011 at 11:51 AM, ATSUSHI TAKAYAMA > wrote: >> >> So converting Blob to ArrayBuffer is only supported through an >> asynchronous API (FileReader's readAsArrayBuffer) except in Workers, >> but the other way round is synchronous? I thought the direction of the >> client side web was to make all API's that might involve disk access >> asynchronous. > > Creating a Blob can be synchronous because it doesn't actually (visibly) > copy or move any data around--that doesn't happen until you actually try to > do something with the data, and all APIs to do *that* are async. > > Even if an implementation needs to hit the disk to make a Blob out of an > ArrayBuffer for some reason, it doesn't have to wait for that to complete > before returning the Blob. It can just return the Blob and complete the > copy asynchronously, since it already knows everything it needs to about the > Blob (its size) in order to return it. > > -- > Glenn Maynard > >
Re: Is BlobBuilder needed?
On Thu, Oct 27, 2011 at 11:51 AM, ATSUSHI TAKAYAMA < taka.atsu...@googlemail.com> wrote: > So converting Blob to ArrayBuffer is only supported through an > asynchronous API (FileReader's readAsArrayBuffer) except in Workers, > but the other way round is synchronous? I thought the direction of the > client side web was to make all API's that might involve disk access > asynchronous. > Creating a Blob can be synchronous because it doesn't actually (visibly) copy or move any data around--that doesn't happen until you actually try to do something with the data, and all APIs to do *that* are async. Even if an implementation needs to hit the disk to make a Blob out of an ArrayBuffer for some reason, it doesn't have to wait for that to complete before returning the Blob. It can just return the Blob and complete the copy asynchronously, since it already knows everything it needs to about the Blob (its size) in order to return it. -- Glenn Maynard
Re: Is BlobBuilder needed?
Hi Jonas and all,
So converting Blob to ArrayBuffer is only supported through an
asynchronous API (FileReader's readAsArrayBuffer) except in Workers,
but the other way round is synchronous? I thought the direction of the
client side web was to make all API's that might involve disk access
asynchronous.
I like the API, though, except on this point.
A. TAKAYAMA
On Mon, Oct 24, 2011 at 6:52 PM, Jonas Sicking wrote:
> Hi everyone,
>
> It was pointed out to me on twitter that BlobBuilder can be replaced
> with simply making Blob constructable. I.e. the following code:
>
> var bb = new BlobBuilder();
> bb.append(blob1);
> bb.append(blob2);
> bb.append("some string");
> bb.append(myArrayBuffer);
> var b = bb.getBlob();
>
> would become
>
> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>
> or look at it another way:
>
> var x = new BlobBuilder();
> becomes
> var x = [];
>
> x.append(y);
> becomes
> x.push(y);
>
> var b = x.getBlob();
> becomes
> var b = new Blob(x);
>
> So at worst there is a one-to-one mapping in code required to simply
> have |new Blob|. At best it requires much fewer lines if the page has
> several parts available at once.
>
> And we'd save a whole class since Blobs already exist.
>
> / Jonas
>
>
Re: Is BlobBuilder needed?
On Thu, 27 Oct 2011 08:14:39 +0900, Jonas Sicking wrote:
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.
Lets call it "type" if it is not actually a Content-Type header value but
a MIME type.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: Is BlobBuilder needed?
On Wed, Oct 26, 2011 at 4:14 PM, Jonas Sicking wrote:
> On Tue, Oct 25, 2011 at 12:57 PM, Tab Atkins Jr. wrote:
>> On Tue, Oct 25, 2011 at 12:53 PM, Ojan Vafai 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.
Re: Is BlobBuilder needed?
var b = new Blob([foo, bar], { contentType: "text/plain" });
This is really nice looking and feeling. Options objects are definitely a win
/rw
On Oct 26, 2011 7:17 PM, Jonas Sicking wrote:
On Tue, Oct 25, 2011 at 12:57 PM, Tab Atkins Jr.
wrote:
> On Tue, Oct 25, 2011 at 12:53 PM, Ojan Vafai
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" })
Thi
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
Re: Is BlobBuilder needed?
On Tue, Oct 25, 2011 at 12:57 PM, Tab Atkins Jr. wrote:
> On Tue, Oct 25, 2011 at 12:53 PM, Ojan Vafai 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
Re: Is BlobBuilder needed?
On Tue, Oct 25, 2011 at 12:57 PM, Tab Atkins Jr. wrote:
> On Tue, Oct 25, 2011 at 12:53 PM, Ojan Vafai 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 agree actually. So, it could be any of the following:
1. new Blob(data, [optional] options)
2. new Blob(options, data...)
3. new Blob([optional] dataAndOptions)
I don't feel strongly, but option 1 seems best to me since it allows simple
usages like 'new Blob("foo")'. On the other hand, option 2 lets you not have
to create an array to append multiple elements to the Blob.
Re: Is BlobBuilder needed?
On Tue, Oct 25, 2011 at 3:53 PM, Ojan Vafai wrote: > I'm happy with this. In theory, vendors could implement this using > copy-on-write or something similar so that this pattern is roughly as > efficient as BlobBuilder, right? > It's simpler than that, since Blob data is immutable; you don't even need copy-on-write, just shallow copies. But you want that with BlobBuilder, too; I don't think this changes anything. -- Glenn Maynard
Re: Is BlobBuilder needed?
+1!
On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking wrote:
> Hi everyone,
>
> It was pointed out to me on twitter that BlobBuilder can be replaced
> with simply making Blob constructable. I.e. the following code:
>
> var bb = new BlobBuilder();
> bb.append(blob1);
> bb.append(blob2);
> bb.append("some string");
> bb.append(myArrayBuffer);
> var b = bb.getBlob();
>
> would become
>
> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>
> or look at it another way:
>
> var x = new BlobBuilder();
> becomes
> var x = [];
>
> x.append(y);
> becomes
> x.push(y);
>
> var b = x.getBlob();
> becomes
> var b = new Blob(x);
>
> So at worst there is a one-to-one mapping in code required to simply
> have |new Blob|. At best it requires much fewer lines if the page has
> several parts available at once.
>
> And we'd save a whole class since Blobs already exist.
>
> / Jonas
>
>
Re: Is BlobBuilder needed?
On Tue, Oct 25, 2011 at 12:53 PM, Ojan Vafai 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. ~TJ
Re: Is BlobBuilder needed?
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); On Tue, Oct 25, 2011 at 11:57 AM, Michael Nordman wrote: > This ultimately amounts to syntactic sugar compared to the existing api. > It's tasty, but adds no new functionality. Also there's still the issue of > how this new api would provide the existing functionality around line > endings, so less functionality at the moment. I'm not opposed to > additions/enhancements, just want to put it in perspective and to question > whether the api churn is worth it. > > On Mon, Oct 24, 2011 at 10:19 PM, Erik Arvidsson wrote: > >> On Mon, Oct 24, 2011 at 19:54, Jonas Sicking wrote: >> > Sure. Though you could also just do >> > >> > var b = new Blob(); >> > b = new Blob([b, data]); >> > b = new Blob([b, moreData]); >> >> That works for me. >> > I'm happy with this. In theory, vendors could implement this using copy-on-write or something similar so that this pattern is roughly as efficient as BlobBuilder, right?
Re: Is BlobBuilder needed?
This ultimately amounts to syntactic sugar compared to the existing api. It's tasty, but adds no new functionality. Also there's still the issue of how this new api would provide the existing functionality around line endings, so less functionality at the moment. I'm not opposed to additions/enhancements, just want to put it in perspective and to question whether the api churn is worth it. On Mon, Oct 24, 2011 at 10:19 PM, Erik Arvidsson wrote: > On Mon, Oct 24, 2011 at 19:54, Jonas Sicking wrote: > > Sure. Though you could also just do > > > > var b = new Blob(); > > b = new Blob([b, data]); > > b = new Blob([b, moreData]); > > That works for me. > > -- > erik > >
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 19:54, Jonas Sicking wrote: > Sure. Though you could also just do > > var b = new Blob(); > b = new Blob([b, data]); > b = new Blob([b, moreData]); That works for me. -- erik
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 10:49 PM, Erik Arvidsson wrote:
> I think the point is that with the old one you could generate lots of
> data, add that to the blob, generate a lot more data and add that to
> the blob. After every add it might be safe to gc that data. With this
> proposal all that data needs to be in memory at the point of
> construction.
>
It doesn't. Each individual "low-level" Blob can be swapped to disk, and
stay there; you don't need to read it into memory to construct new Blobs
containing it.
Repeating my earlier example:
var b = new Blob();
ongotdataevent = function(blobToAppend) { b = new Blob(b, blobToAppend); }
You don't need to have any of the previous Blobs in memory when you create
each new compound Blob; you only need to know where to get them later, and
their size.
> Could we add a concat like method to Blob that returns a new "larger" blob?
>
> var bb = new BlobBuilder();
> bb.append(data);
> bb.append(moreData);
> var b = bb.getBlob();
>
This is the same as the above: new Blob(data, moreData). There's no need
for a special method for this.
--
Glenn Maynard
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 7:49 PM, Erik Arvidsson wrote: > On Mon, Oct 24, 2011 at 19:23, Jonas Sicking wrote: >>> 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? > > I think the point is that with the old one you could generate lots of > data, add that to the blob, generate a lot more data and add that to > the blob. After every add it might be safe to gc that data. With this > proposal all that data needs to be in memory at the point of > construction. > > Could we add a concat like method to Blob that returns a new "larger" blob? > > var bb = new BlobBuilder(); > bb.append(data); > bb.append(moreData); > var b = bb.getBlob(); > > var b = new Blob(); > b = b.concat(data); > b = b.concat(moreData); Sure. Though you could also just do var b = new Blob(); b = new Blob([b, data]); b = new Blob([b, moreData]); I don't really have a strong preference for we should have .concat as well or not. Array and String both have a lot of redundant methods for concatenating and splitting data. / Jonas
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 7:49 PM, Erik Arvidsson wrote: > On Mon, Oct 24, 2011 at 19:23, Jonas Sicking wrote: > >> 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? > > I think the point is that with the old one you could generate lots of > data, add that to the blob, generate a lot more data and add that to > the blob. After every add it might be safe to gc that data. With this > proposal all that data needs to be in memory at the point of > construction. > > Could we add a concat like method to Blob that returns a new "larger" blob? > If concat also took an array and/or varargs, then I'd be happy with this and getting rid of BlobBuilder. > var bb = new BlobBuilder(); > bb.append(data); > bb.append(moreData); > var b = bb.getBlob(); > > var b = new Blob(); > b = b.concat(data); > b = b.concat(moreData); > > -- > erik >
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 19:23, Jonas Sicking wrote: >> 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? I think the point is that with the old one you could generate lots of data, add that to the blob, generate a lot more data and add that to the blob. After every add it might be safe to gc that data. With this proposal all that data needs to be in memory at the point of construction. Could we add a concat like method to Blob that returns a new "larger" blob? var bb = new BlobBuilder(); bb.append(data); bb.append(moreData); var b = bb.getBlob(); var b = new Blob(); b = b.concat(data); b = b.concat(moreData); -- erik
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 16:46, Tab Atkins Jr. wrote:
> 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
> }
Nope. The rest parameter must be the last parameter.
This is already in the latest draft for edition 6.
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
See "13 Function Definition".
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 7:11 PM, Ojan Vafai wrote:
> On Mon, Oct 24, 2011 at 6:40 PM, Jonas Sicking wrote:
>>
>> On Mon, Oct 24, 2011 at 4:46 PM, Tab Atkins Jr.
>> wrote:
>> > On Mon, Oct 24, 2011 at 4:33 PM, Eric U 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
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 6:40 PM, Jonas Sicking wrote:
> On Mon, Oct 24, 2011 at 4:46 PM, Tab Atkins Jr.
> wrote:
> > On Mon, Oct 24, 2011 at 4:33 PM, Eric U 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.
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
>
>
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 4:46 PM, Tab Atkins Jr. wrote:
> On Mon, Oct 24, 2011 at 4:33 PM, Eric U 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.
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");
is significantly better than
new Blob([blob1, blob2, mybuffer, blob3, "somestring"], "text/plain");
/ Jonas
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 4:33 PM, Eric U 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
}
~TJ
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 4:33 PM, Eric U wrote:
> On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking wrote:
>> Hi everyone,
>>
>> It was pointed out to me on twitter that BlobBuilder can be replaced
>> with simply making Blob constructable. I.e. the following code:
>>
>> var bb = new BlobBuilder();
>> bb.append(blob1);
>> bb.append(blob2);
>> bb.append("some string");
>> bb.append(myArrayBuffer);
>> var b = bb.getBlob();
>>
>> would become
>>
>> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>>
>> or look at it another way:
>>
>> var x = new BlobBuilder();
>> becomes
>> var x = [];
>>
>> x.append(y);
>> becomes
>> x.push(y);
>>
>> var b = x.getBlob();
>> becomes
>> var b = new Blob(x);
>>
>> So at worst there is a one-to-one mapping in code required to simply
>> have |new Blob|. At best it requires much fewer lines if the page has
>> several parts available at once.
>>
>> And we'd save a whole class since Blobs already exist.
>
> It does look cleaner this way, and getting rid of a whole class would
> be very nice.
>
> 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?
The content-type can and should be added to the ctor.
Line-endings is a problem though. I'm not fully sure what the use case
is for them, and the spec does have an issue-marked asking if
line-ending conversion is needed at all. Worst case we could do them
as a separate function which does native-lineending-conversion for a
string.
I'm not fully sold on the var-args thing. It gets very awkward with
the content-type argument, and like you point out, it does make the
API less future proof.
It's also a bit scary to rely on a ES6 feature while ES6 is as
unstable as it still is.
/ Jonas
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking wrote:
> Hi everyone,
>
> It was pointed out to me on twitter that BlobBuilder can be replaced
> with simply making Blob constructable. I.e. the following code:
>
> var bb = new BlobBuilder();
> bb.append(blob1);
> bb.append(blob2);
> bb.append("some string");
> bb.append(myArrayBuffer);
> var b = bb.getBlob();
>
> would become
>
> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>
> or look at it another way:
>
> var x = new BlobBuilder();
> becomes
> var x = [];
>
> x.append(y);
> becomes
> x.push(y);
>
> var b = x.getBlob();
> becomes
> var b = new Blob(x);
>
> So at worst there is a one-to-one mapping in code required to simply
> have |new Blob|. At best it requires much fewer lines if the page has
> several parts available at once.
>
> And we'd save a whole class since Blobs already exist.
It does look cleaner this way, and getting rid of a whole class would
be very nice.
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?
Eric
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 4:15 PM, Michael Nordman wrote: > It's nice. Like Ojan said, I don't see this as mutually exlusive with > BlobBuilder either. There's nother peice of data to associate with a blob... > the content-type... that would need to be provided in the ctor. Good point. Which makes it much harder to use the ES6 fancyness. / Jonas
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 6:52 PM, Jonas Sicking wrote:
> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>
To give another comparison, this incremental appending:
bb = new BlobBuilder();
ongotdataevent = function(blobToAppend) { bb.append(blobToAppend); }
ondatafinishedevent = function() { b = bb.getBlob(); }
can become:
var b = new Blob();
ongotdataevent = function(blobToAppend) { b = new Blob(b, blobToAppend); }
which is nice, too. (UAs should optimize this to avoid O(n^2) copying, of
course.)
On Mon, Oct 24, 2011 at 7:01 PM, Ojan Vafai wrote:
> In theory, a BlobBuilder could be backed by a file on disk, no? The
> advantage is that if you're building something very large, you don't
> necessarily need to be using all that memory. You can imagine a UA having
> Blobs be fully in-memory until they cross some size threshold.
>
Blobs, or parts of Blobs, can be backed by files on disk too. You don't
need BlobBuilder to get that functionality.
--
Glenn Maynard
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 4:01 PM, Ojan Vafai wrote: > In theory, a BlobBuilder could be backed by a file on disk, no? The > advantage is that if you're building something very large, you don't > necessarily need to be using all that memory. You can imagine a UA having > Blobs be fully in-memory until they cross some size threshold. It does seem like something of an edge case to add a very big string or arraybuffer and then keep the BlobBuilder alive for long enough after that that both the string/arraybuffer is otherwise GC'ed, *and* that that memory usage is an issue. Worst case you can always change x.push(mylargestring); into x.push(new Blob(mylargestring)); and then the UA should be able to do the same optimization. / Jonas
Re: Is BlobBuilder needed?
It's nice. Like Ojan said, I don't see this as mutually exlusive with
BlobBuilder either. There's nother peice of data to associate with a
blob... the content-type... that would need to be provided in the ctor.
On Mon, Oct 24, 2011 at 4:01 PM, Ojan Vafai wrote:
> On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking wrote:
>
>> Hi everyone,
>>
>> It was pointed out to me on twitter that BlobBuilder can be replaced
>> with simply making Blob constructable. I.e. the following code:
>>
>> var bb = new BlobBuilder();
>> bb.append(blob1);
>> bb.append(blob2);
>> bb.append("some string");
>> bb.append(myArrayBuffer);
>> var b = bb.getBlob();
>>
>> would become
>>
>> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>>
>
> I like this API. I think we should add it regardless of whether we get rid
> of BlobBuilder. I'd slightly prefer saying that Blob takes varargs and rely
> on ES6 fanciness to expand the array into varargs.
>
> In theory, a BlobBuilder could be backed by a file on disk, no? The
> advantage is that if you're building something very large, you don't
> necessarily need to be using all that memory. You can imagine a UA having
> Blobs be fully in-memory until they cross some size threshold.
>
>
>> or look at it another way:
>>
>> var x = new BlobBuilder();
>> becomes
>> var x = [];
>>
>> x.append(y);
>> becomes
>> x.push(y);
>>
>> var b = x.getBlob();
>> becomes
>> var b = new Blob(x);
>>
>> So at worst there is a one-to-one mapping in code required to simply
>> have |new Blob|. At best it requires much fewer lines if the page has
>> several parts available at once.
>>
>> And we'd save a whole class since Blobs already exist.
>>
>> / Jonas
>>
>>
>
Re: Is BlobBuilder needed?
Yeah, this is easily a win for the web platform. Smaller, more concise
API. I like it.
As Ojan said; Please use rest params here so that there is no need to
create the extra array.
erik
On Mon, Oct 24, 2011 at 16:07, Rick Waldron wrote:
> From a real-world developer perpective, this API modification is a win.
>
> On Mon, Oct 24, 2011 at 7:01 PM, Ojan Vafai wrote:
>>
>> On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking wrote:
>>>
>>> Hi everyone,
>>>
>>> It was pointed out to me on twitter that BlobBuilder can be replaced
>>> with simply making Blob constructable. I.e. the following code:
>>>
>>> var bb = new BlobBuilder();
>>> bb.append(blob1);
>>> bb.append(blob2);
>>> bb.append("some string");
>>> bb.append(myArrayBuffer);
>>> var b = bb.getBlob();
>>>
>>> would become
>>>
>>> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>>
>> I like this API. I think we should add it regardless of whether we get rid
>> of BlobBuilder. I'd slightly prefer saying that Blob takes varargs and rely
>> on ES6 fanciness to expand the array into varargs.
>> In theory, a BlobBuilder could be backed by a file on disk, no? The
>> advantage is that if you're building something very large, you don't
>> necessarily need to be using all that memory. You can imagine a UA having
>> Blobs be fully in-memory until they cross some size threshold.
>>
>>>
>>> or look at it another way:
>>>
>>> var x = new BlobBuilder();
>>> becomes
>>> var x = [];
>>>
>>> x.append(y);
>>> becomes
>>> x.push(y);
>>>
>>> var b = x.getBlob();
>>> becomes
>>> var b = new Blob(x);
>>>
>>> So at worst there is a one-to-one mapping in code required to simply
>>> have |new Blob|. At best it requires much fewer lines if the page has
>>> several parts available at once.
>>>
>>> And we'd save a whole class since Blobs already exist.
>>>
>>> / Jonas
>>>
>>
>
>
Re: Is BlobBuilder needed?
>From a real-world developer perpective, this API modification is a win.
On Mon, Oct 24, 2011 at 7:01 PM, Ojan Vafai wrote:
> On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking wrote:
>
>> Hi everyone,
>>
>> It was pointed out to me on twitter that BlobBuilder can be replaced
>> with simply making Blob constructable. I.e. the following code:
>>
>> var bb = new BlobBuilder();
>> bb.append(blob1);
>> bb.append(blob2);
>> bb.append("some string");
>> bb.append(myArrayBuffer);
>> var b = bb.getBlob();
>>
>> would become
>>
>> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>>
>
> I like this API. I think we should add it regardless of whether we get rid
> of BlobBuilder. I'd slightly prefer saying that Blob takes varargs and rely
> on ES6 fanciness to expand the array into varargs.
>
> In theory, a BlobBuilder could be backed by a file on disk, no? The
> advantage is that if you're building something very large, you don't
> necessarily need to be using all that memory. You can imagine a UA having
> Blobs be fully in-memory until they cross some size threshold.
>
>
>> or look at it another way:
>>
>> var x = new BlobBuilder();
>> becomes
>> var x = [];
>>
>> x.append(y);
>> becomes
>> x.push(y);
>>
>> var b = x.getBlob();
>> becomes
>> var b = new Blob(x);
>>
>> So at worst there is a one-to-one mapping in code required to simply
>> have |new Blob|. At best it requires much fewer lines if the page has
>> several parts available at once.
>>
>> And we'd save a whole class since Blobs already exist.
>>
>> / Jonas
>>
>>
>
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking wrote:
> Hi everyone,
>
> It was pointed out to me on twitter that BlobBuilder can be replaced
> with simply making Blob constructable. I.e. the following code:
>
> var bb = new BlobBuilder();
> bb.append(blob1);
> bb.append(blob2);
> bb.append("some string");
> bb.append(myArrayBuffer);
> var b = bb.getBlob();
>
> would become
>
> b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
>
I like this API. I think we should add it regardless of whether we get rid
of BlobBuilder. I'd slightly prefer saying that Blob takes varargs and rely
on ES6 fanciness to expand the array into varargs.
In theory, a BlobBuilder could be backed by a file on disk, no? The
advantage is that if you're building something very large, you don't
necessarily need to be using all that memory. You can imagine a UA having
Blobs be fully in-memory until they cross some size threshold.
> or look at it another way:
>
> var x = new BlobBuilder();
> becomes
> var x = [];
>
> x.append(y);
> becomes
> x.push(y);
>
> var b = x.getBlob();
> becomes
> var b = new Blob(x);
>
> So at worst there is a one-to-one mapping in code required to simply
> have |new Blob|. At best it requires much fewer lines if the page has
> several parts available at once.
>
> And we'd save a whole class since Blobs already exist.
>
> / Jonas
>
>
Is BlobBuilder needed?
Hi everyone,
It was pointed out to me on twitter that BlobBuilder can be replaced
with simply making Blob constructable. I.e. the following code:
var bb = new BlobBuilder();
bb.append(blob1);
bb.append(blob2);
bb.append("some string");
bb.append(myArrayBuffer);
var b = bb.getBlob();
would become
b = new Blob([blob1, blob2, "some string", myArrayBuffer]);
or look at it another way:
var x = new BlobBuilder();
becomes
var x = [];
x.append(y);
becomes
x.push(y);
var b = x.getBlob();
becomes
var b = new Blob(x);
So at worst there is a one-to-one mapping in code required to simply
have |new Blob|. At best it requires much fewer lines if the page has
several parts available at once.
And we'd save a whole class since Blobs already exist.
/ Jonas
