Re: [FileAPI] Deterministic release of Blob proposal

On Wed, Mar 7, 2012 at 5:58 PM, Feras Moussa wrote: > In the case where close was called on a Blob that is being used in a > pending request, then the request should be canceled. The expected > result is the same as if abort() was called. > This would complicate every API that uses Blobs. APIs

Re: [FileAPI] Deterministic release of Blob proposal

On Thu, 08 Mar 2012 00:58:02 +0100, Feras Moussa wrote: In the case where close was called on a Blob that is being used in a pending request, then the request should be canceled. The expected result is the same as if abort() was called. It seems very weird that invoking close() on Blob would

Re: [FileAPI] Deterministic release of Blob proposal

On 3/7/12 3:56 PM, Feras Moussa wrote: Then let's try this again. var a = new Image(); a.onerror = function() { console.log("Oh no, my parent was neutered!"); }; a.src = URL.createObjectURL(blob); blob.close(); Is that error going to hit? until it has been revoked, so in your example onerror

RE: [FileAPI] Deterministic release of Blob proposal

> -Original Message- > From: Anne van Kesteren [mailto:ann...@opera.com] > Sent: Wednesday, March 07, 2012 12:49 AM > To: Arun Ranganathan; Feras Moussa > Cc: Adrian Bateman; public-webapps@w3.org; Ian Hickson > Subject: Re: [FileAPI] Deterministic release of Blob prop

RE: [FileAPI] Deterministic release of Blob proposal

> Then let's try this again. > > var a = new Image(); > a.onerror = function() { console.log("Oh no, my parent was neutered!"); }; > a.src = URL.createObjectURL(blob); blob.close(); > > Is that error going to hit? I documented this in my proposal, but in this case the URI would have been minted p

Re: [FileAPI] Deterministic release of Blob proposal

On Tue, Mar 6, 2012 at 5:12 PM, Feras Moussa wrote: >> From: Arun Ranganathan [mailto:aranganat...@mozilla.com] >> Sent: Tuesday, March 06, 2012 1:27 PM >> To: Feras Moussa >> Cc: Adrian Bateman; public-webapps@w3.org; Ian Hickson; Anne van Kesteren >> Subject: Re: [

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On Wed, Mar 7, 2012 at 1:00 PM, Charles Pritchard wrote: > On 3/7/12 12:34 PM, Kenneth Russell wrote: >> >> On Wed, Mar 7, 2012 at 12:02 PM, Charles Pritchard >>  wrote: >>> >>> On Mar 7, 2012, at 11:38 AM, Kenneth Russell  wrote: >>> I believe that we should fix the immediate problem and add

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On 3/7/12 12:34 PM, Kenneth Russell wrote: On Wed, Mar 7, 2012 at 12:02 PM, Charles Pritchard wrote: On Mar 7, 2012, at 11:38 AM, Kenneth Russell wrote: I believe that we should fix the immediate problem and add a close() method to Blob. I'm not in favor of adding a similar method to ArrayBu

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On Wed, Mar 7, 2012 at 12:02 PM, Charles Pritchard wrote: > > On Mar 7, 2012, at 11:38 AM, Kenneth Russell wrote: > >> On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard wrote: >>> On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman wrote: > You can always call close() yourself, but Blob.close(

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On Tue, Mar 6, 2012 at 1:18 PM, Kenneth Russell wrote: > On Tue, Mar 6, 2012 at 12:04 PM, Greg Billock wrote: >> On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard wrote: >>> On 3/5/2012 5:56 PM, Glenn Maynard wrote: >>> >>> On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard wrote: Do y

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On Mar 7, 2012, at 11:38 AM, Kenneth Russell wrote: > On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard wrote: >> On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman wrote: >>> You can always call close() yourself, but Blob.close() should use the "neuter" mechanism already there, not make u

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On Wed, Mar 7, 2012 at 11:38 AM, Kenneth Russell wrote: > On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard wrote: >> On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman wrote: >>> >>> > You can always call close() yourself, but Blob.close() should use the >>> > "neuter" mechanism already there, not mak

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard wrote: > On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman wrote: >> >> > You can always call close() yourself, but Blob.close() should use the >> > "neuter" mechanism already there, not make up a new one. >> >> Blobs aren't transferable, there is no ex

Re: [FileAPI] Deterministic release of Blob proposal

On Wed, 07 Mar 2012 02:12:39 +0100, Feras Moussa wrote: xhr.send(blob); blob.close(); // method name TBD In our implementation, this case would fail. We think this is reasonable because the need for having a close() method is to allow deterministic release of the resource. Reasonable or

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman wrote: > > You can always call close() yourself, but Blob.close() should use the > > "neuter" mechanism already there, not make up a new one. > > Blobs aren't transferable, there is no existing mechanism that applies > to them. Adding a blob.close()

Re: [FileAPI] Deterministic release of Blob proposal

On 3/6/12 5:12 PM, Feras Moussa wrote: > > frameRef.src = URL.createObjectURL(blob); > blob.close() // method name TBD > > In my opinion, the first (using xhr) should succeed. In the second, frameRef.src works, > but subsequent attempts to mint a Blob URI for the same 'blob' resource fail.

RE: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

Re: Transferable and structured clones, was: Re: [FileAPI] > Deterministic release of Blob proposal > > Ken, > > > I'm not sure that adding close() to Transferable is a good idea. Not > > all Transferable types may want to support that explicit operation. > > Wha

RE: [FileAPI] Deterministic release of Blob proposal

> From: Arun Ranganathan [mailto:aranganat...@mozilla.com] > Sent: Tuesday, March 06, 2012 1:27 PM > To: Feras Moussa > Cc: Adrian Bateman; public-webapps@w3.org; Ian Hickson; Anne van Kesteren > Subject: Re: [FileAPI] Deterministic release of Blob proposal > > Feras, >

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On Mar 6, 2012, at 2:25 PM, Kenneth Russell wrote: > On Tue, Mar 6, 2012 at 1:31 PM, Arun Ranganathan > wrote: >> Ken, >> >>> I'm not sure that adding close() to Transferable is a good idea. Not >>> all Transferable types may want to support that explicit operation. >>> What about adding close(

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On Tue, Mar 6, 2012 at 1:31 PM, Arun Ranganathan wrote: > Ken, > >> I'm not sure that adding close() to Transferable is a good idea. Not >> all Transferable types may want to support that explicit operation. >> What about adding close() to Blob, and having the neutering operation >> on Blob be def

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

>> Separately defining blobs to be transferrable feels like an unneeded >> complexity. A caller wishing to >> neuter after sending can explicit call .close() rather than relying on >> more obscure artifacts of having also put the 'blob' in a >> 'transferrable' array. > > > You can always call close

Re: [FileAPI] Deterministic release of Blob proposal

(I wish people wouldn't split threads.) On Tue, Mar 6, 2012 at 2:29 PM, Eric U wrote: > What about: > >XHR.send(blob); >blob.close(); > This is the same as: XHR.send(arrayBuffer); postMessage({foo: arrayBuffer}, [arrayBuffer]); which you can already do. Both of these should a

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On Tue, Mar 6, 2012 at 3:18 PM, Kenneth Russell wrote: > A change like this would be feasible as long as it doesn't break > compatibility. In other words, the current Transferable array would > still need to be supported, but Transferable instances (or perhaps > instances of some other type) wrapp

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

Sounds like there's a good case for an explicit blob.close() method independent of 'transferable'. Separately defining blobs to be transferrable feels like an unneeded complexity. A caller wishing to neuter after sending can explicit call .close() rather than relying on more obscure artifacts of ha

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

Ken, > I'm not sure that adding close() to Transferable is a good idea. Not > all Transferable types may want to support that explicit operation. > What about adding close() to Blob, and having the neutering operation > on Blob be defined to call close() on it? Specifically, you think this is no

Re: [FileAPI] Deterministic release of Blob proposal

Feras, In practice, I think this is important enough and manageable enough to include in the spec., and I'm willing to slow the train down if necessary, but I'd like to understand a few things first. Below: - Original Message - > At TPAC we discussed the ability to deterministically

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On Tue, Mar 6, 2012 at 12:04 PM, Greg Billock wrote: > On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard wrote: >> On 3/5/2012 5:56 PM, Glenn Maynard wrote: >> >> On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard wrote: >>> >>> Do you see old behavior working something like the following? >>> >>

Re: [FileAPI] Deterministic release of Blob proposal

It seems like this may be setting up a pattern for other dom objects which are large (like video/audio). When applied in this context, is "close" still a good verb for them? video.close(); dave PS I'm trying to not bikeshed too badly by avoiding a new name suggestion and allowing for the fact

Re: [FileAPI] Deterministic release of Blob proposal

After a brief internal discussion, we like the idea over in Chrome-land. Let's make sure that we carefully spec out the edge cases, though. See below for some. On Fri, Mar 2, 2012 at 4:54 PM, Feras Moussa wrote: > At TPAC we discussed the ability to deterministically close blobs with a few > > ot

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard wrote: > On 3/5/2012 5:56 PM, Glenn Maynard wrote: > > On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard wrote: >> >> Do you see old behavior working something like the following? >> >> >> var blob = new Blob("my new big blob"); >> var keepBlob =

Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On 3/5/2012 5:56 PM, Glenn Maynard wrote: On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard > wrote: Do you see old behavior working something like the following? var blob = new Blob("my new big blob"); var keepBlob = blob.slice(); destination.postMessage(bl

Re: [FileAPI] Deterministic release of Blob proposal

On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard wrote: > Do you see old behavior working something like the following? > > var blob = new Blob("my new big blob"); > var keepBlob = blob.slice(); > destination.postMessage(blob, '*', [blob]); // is try/catch needed here? > blob = keepBlob; // ke

Re: [FileAPI] Deterministic release of Blob proposal

On 3/5/2012 3:59 PM, Glenn Maynard wrote: On Fri, Mar 2, 2012 at 6:54 PM, Feras Moussa > wrote: To address this issue, we propose that a close method be added to the Blob interface. When called, the close method should release the underlying res

Re: [FileAPI] Deterministic release of Blob proposal

On Fri, Mar 2, 2012 at 6:54 PM, Feras Moussa wrote: > To address this issue, we propose that a close method be added to the Blob > > > interface. > > When called, the close method should release the underlying resource of > the > > Blob, and future operations on the Blob will return

RE: [FileAPI] Deterministic release of Blob proposal

in apps which make extensive use of the APIs. > -Original Message- > From: Arthur Barstow [mailto:art.bars...@nokia.com] > Sent: Monday, March 05, 2012 12:52 PM > To: Feras Moussa; Arun Ranganathan; Jonas Sicking > Cc: public-webapps@w3.org; Adrian Bateman > Subject: Re: [

Re: [FileAPI] Deterministic release of Blob proposal

Feras - this seems kinda' late, especially since the two-week pre-LC comment period for File API ended Feb 24. Is this a feature that can be postponed to v.next? On 3/2/12 7:54 PM, ext Feras Moussa wrote: At TPAC we discussed the ability to deterministically close blobs with a few others.

Re: [FileAPI] Deterministic release of Blob proposal

On 3/2/2012 4:54 PM, Feras Moussa wrote: At TPAC we discussed the ability to deterministically close blobs with a few others. ... To address this issue, we propose that a close method be added to the Blob interface. When called, the close method should release the underlying resource

[FileAPI] Deterministic release of Blob proposal

At TPAC we discussed the ability to deterministically close blobs with a few others. As we've discussed in the createObjectURL thread[1], a Blob may represent an expensive resource (eg. expensive in terms of memory, battery, or disk space). At present there is no way for an application to determin