Re: [FileAPI] createObjectURL isReusable proposal

2012-03-27 Thread Robert O'Callahan
On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson i...@hixie.ch wrote: Anything's possible, but I think the pain here would far outweigh the benefits. There would be some really hard questions to answer, too (e.g. what would

Re: [FileAPI] createObjectURL isReusable proposal

2012-03-27 Thread Bronislav Klučka
On 27.3.2012 11:43, Robert O'Callahan wrote: On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson i...@hixie.ch mailto:i...@hixie.ch wrote: Anything's possible, but I think the pain here would far outweigh the

RE: [FileAPI] createObjectURL isReusable proposal

2012-02-29 Thread Feras Moussa
with these changes in any way possible. Thanks, Feras -Original Message- From: Bronislav Klučka [mailto:bronislav.klu...@bauglir.com] Sent: Friday, February 24, 2012 1:10 PM To: public-webapps@w3.org Cc: public-webapps@w3.org Subject: Re: [FileAPI] createObjectURL isReusable proposal

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-29 Thread Glenn Maynard
On Wed, Feb 29, 2012 at 9:38 PM, Feras Moussa fer...@microsoft.com wrote: Another case: whether loading a one-shot URL from a different origin, where you aren't allowed to load the content, still causes the URL to be revoked. (My first impression was that it shouldn't affect it at all, but

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-29 Thread Bronislav Klučka
On 1.3.2012 4:38, Feras Moussa wrote: We think the new property bag (objectURLOptions) semantics in the latest editors draft are very reasonable. We have an implementation of this and from our experience have found it very widely used internally with app developers - many leverage it as a way

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-24 Thread Arun Ranganathan
Bronislav, I could also go with reverse approach, with createObjectURL being oneTimeOnly by default createObjectURL(Blob aBlob, boolean? isPermanent) instead of current createObjectURL(Blob aBlob, boolean? isOneTime) the fact, that user would have to explicitly specify, that such URL is

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-24 Thread Bronislav Klučka
On 24.2.2012 20:12, Arun Ranganathan wrote: Bronislav, I could also go with reverse approach, with createObjectURL being oneTimeOnly by default createObjectURL(Blob aBlob, boolean? isPermanent) instead of current createObjectURL(Blob aBlob, boolean? isOneTime) the fact, that user would have

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-24 Thread Arun Ranganathan
On 24.2.2012 20:12, Arun Ranganathan wrote: Bronislav, I could also go with reverse approach, with createObjectURL being oneTimeOnly by default createObjectURL(Blob aBlob, boolean? isPermanent) instead of current createObjectURL(Blob aBlob, boolean? isOneTime) the fact, that

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-14 Thread Bronislav Klučka
On 14.2.2012 5:56, Jonas Sicking wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-14 Thread Charles Pritchard
On 2/14/2012 5:35 AM, Bronislav Klučka wrote: On 14.2.2012 5:56, Jonas Sicking wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-14 Thread Bronislav Klučka
On 14.2.2012 14:39, Charles Pritchard wrote: On 2/14/2012 5:35 AM, Bronislav Klučka wrote: On 14.2.2012 5:56, Jonas Sicking wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-14 Thread Glenn Maynard
2012/2/14 Bronislav Klučka bronislav.klu...@bauglir.com The point of reusable Blob URL is the compatibility with regular URL, not having reusable URL would create unpleasant dichotomy in data manipulating... The point is avoiding the error-prone need to release resources by hand. -- Glenn

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-14 Thread Bronislav Klučka
On 14.2.2012 15:20, Glenn Maynard wrote: 2012/2/14 Bronislav Klučka bronislav.klu...@bauglir.com mailto:bronislav.klu...@bauglir.com The point of reusable Blob URL is the compatibility with regular URL, not having reusable URL would create unpleasant dichotomy in data

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-14 Thread Bronislav Klučka
On 14.2.2012 5:56, Jonas Sicking wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-13 Thread Jonas Sicking
On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful in mitigating some of our fears. Hixie,

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-04 Thread Bronislav Klučka
On 4.2.2012 5:55, Glenn Maynard wrote: 2012/2/3 Bronislav Klučka bronislav.klu...@bauglir.com mailto:bronislav.klu...@bauglir.com How would you create copies programmaticaly? How would you reassign src attribute of one image to another? The idea, that sometimes the attribute

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-04 Thread Glenn Maynard
If you can't be civil, I'm not going to discuss with you. 2012/2/4 Bronislav Klučka bronislav.klu...@bauglir.com On 4.2.2012 5:55, Glenn Maynard wrote: 2012/2/3 Bronislav Klučka bronislav.klu...@bauglir.com mailto: Bronislav.Klucka@**bauglir.com bronislav.klu...@bauglir.com How would

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-03 Thread Anne van Kesteren
On Thu, 02 Feb 2012 22:40:12 +0100, Ian Hickson i...@hixie.ch wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful in mitigating some of our fears.

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-03 Thread Bronislav Klučka
On 3.2.2012 15:13, Anne van Kesteren wrote: On Thu, 02 Feb 2012 22:40:12 +0100, Ian Hickson i...@hixie.ch wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-03 Thread Glenn Maynard
2012/2/3 Bronislav Klučka bronislav.klu...@bauglir.com How would you create copies programmaticaly? How would you reassign src attribute of one image to another? The idea, that sometimes the attribute would return string (regular URL, FileSystem APi URL) sometimes Blob... What would you do

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-02 Thread Arun Ranganathan
On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson i...@hixie.ch wrote: (From Glenn Maynard) I think it's dangerous to assume that the URL will only be dereferenced once. For example, it would mean that the above image would break if the user toggled images off and back on in a

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-02 Thread Ian Hickson
On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful in mitigating some of our fears. Hixie, is this possible? Anything's possible, but I think the pain

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-02 Thread Charles Pritchard
On Feb 2, 2012, at 1:40 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 2 Feb 2012, Arun Ranganathan wrote: 2. Could we modify things so that img.src = blob is a reality? Mainly, if we modify things for the *most common* use case, that could be useful in mitigating some of our fears.

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-02 Thread Kyle Huey
On Thu, Feb 2, 2012 at 4:48 PM, Charles Pritchard ch...@jumis.com wrote: Blob.prototype.toString=function(){ return URL.createObjectURL(this); }; We *really* don't want to make a function that gets automatically called leak memory like this. - Kyle

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-02 Thread Bronislav Klučka
On 2.2.2012 21:25, Arun Ranganathan wrote: Well, I'm a fan of img.src = blob being made a reality, *and* of the URL API being solidified. I'm not 100% sure how we can scope create* to an Element in the DOM. While open to a suggestion that clarifies your thoughts on this, I'm worried that

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-02 Thread Bronislav Klučka
On 28.1.2012 8:47, Ian Hickson wrote: On Sat, 28 Jan 2012, Kyle Huey wrote: On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisherda...@chromium.org wrote: I'm not sure what a concrete proposal would look like. Maybe Element.URL.createObjectURL or just Element.createObjectURL? Wouldn't returning

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-02 Thread Bronislav Klučka
On 3.2.2012 7:34, Bronislav Klučka wrote: On 28.1.2012 8:47, Ian Hickson wrote: On Sat, 28 Jan 2012, Kyle Huey wrote: On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisherda...@chromium.org wrote: I'm not sure what a concrete proposal would look like. Maybe Element.URL.createObjectURL or just

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-02 Thread Charles Pritchard
On 2/2/12 10:40 PM, Bronislav Klučka wrote: On 3.2.2012 7:34, Bronislav Klučka wrote: On 28.1.2012 8:47, Ian Hickson wrote: On Sat, 28 Jan 2012, Kyle Huey wrote: On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisherda...@chromium.org wrote: I'm not sure what a concrete proposal would look like.

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-02 Thread Bronislav Klučka
On 3.2.2012 7:51, Charles Pritchard wrote: On 2/2/12 10:40 PM, Bronislav Klučka wrote: On 3.2.2012 7:34, Bronislav Klučka wrote: On 28.1.2012 8:47, Ian Hickson wrote: On Sat, 28 Jan 2012, Kyle Huey wrote: On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisherda...@chromium.org wrote: I'm not

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-02 Thread Charles Pritchard
On 2/2/12 11:08 PM, Bronislav Klučka wrote: On 3.2.2012 7:51, Charles Pritchard wrote: I see no reason why an author should expect to stash 100MB of objects into createObjectURL, nor any reason why a UA could not manage 100MB for the application lifetime; the user can certainly be informed, as

Re: [FileAPI] createObjectURL isReusable proposal

2012-02-02 Thread Bronislav Klučka
On 3.2.2012 8:24, Charles Pritchard wrote: On 2/2/12 11:08 PM, Bronislav Klučka wrote: On 3.2.2012 7:51, Charles Pritchard wrote: I see no reason why an author should expect to stash 100MB of objects into createObjectURL, nor any reason why a UA could not manage 100MB for the application

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-30 Thread Kyle Huey
2012/1/28 Bronislav Klučka bronislav.klu...@bauglir.com img.src = blob; tells nothing about possible access to underlying data using URL identifier And I think that if we're concerned about the blob being leaked for the lifetime of the document (because the URL was never revoked) we should

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-30 Thread Glenn Maynard
2012/1/30 Bronislav Klučka bronislav.klu...@bauglir.com it would seem that you do not understand the point here... if we allow img.src = blob approach we would HAVE TO have memory management on language level as well, either URL reference or blob must be freed/nulled/whatever somewhere. This

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-30 Thread Bronislav Klučka
On 30.1.2012 15:18, Glenn Maynard wrote: 2012/1/30 Bronislav Klučka bronislav.klu...@bauglir.com mailto:bronislav.klu...@bauglir.com it would seem that you do not understand the point here... if we allow img.src = blob approach we would HAVE TO have memory management on language

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-30 Thread Glenn Maynard
2012/1/30 Bronislav Klučka bronislav.klu...@bauglir.com And how? Using src attribute? that would have to be changed to accept both string and Blob object? What it would return on get operation? Libraries managing images (lightboxes) would have to consider, what does src mean? Or do you

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-30 Thread Bronislav Klučka
On 30.1.2012 16:14, Glenn Maynard wrote: 2012/1/30 Bronislav Klučka bronislav.klu...@bauglir.com mailto:bronislav.klu...@bauglir.com And how? Using src attribute? that would have to be changed to accept both string and Blob object? What it would return on get operation? Libraries

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-30 Thread Bronislav Klučka
On 30.1.2012 16:56, Boris Zbarsky wrote: On 1/30/12 10:40 AM, Bronislav Klučka wrote: img1 = document.getElementById(my-image); img1.src = URL.createObjectUrl(myBlob); img2.src = img1.src; should work like a charm and the URL and blob will be released as soon as all references will be 0

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-30 Thread Kyle Huey
2012/1/30 Bronislav Klučka bronislav.klu...@bauglir.com so just a line URL.createObjectUrl(blob) creates a memory leak? Heh? Which brink me to my previous question, what happened to Blob.URL? Just brink it back and this whole conversation can go away... The only way blob.URL differs from

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-30 Thread Boris Zbarsky
On 1/30/12 11:15 AM, Bronislav Klučka wrote: In this case you got me... what sense does it make? If there is no reference to original blob or any other object using that URL, why is it kept? Because given a string there is no way to tell whether someone has a reference it. Consider this:

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-30 Thread Bronislav Klučka
On 30.1.2012 17:29, Boris Zbarsky wrote: On 1/30/12 11:15 AM, Bronislav Klučka wrote: In this case you got me... what sense does it make? If there is no reference to original blob or any other object using that URL, why is it kept? Because given a string there is no way to tell whether

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-30 Thread Boris Zbarsky
On 1/30/12 11:44 AM, Bronislav Klučka wrote: Both could be solved by Blob.URL, there is no strange string somehow connected to blob. Blob belongs to URL and URL belongs to blob... who cares how exactly is the string created (split - join), it is string identification, not pointer reference...

Fwd: Re: [FileAPI] createObjectURL isReusable proposal

2012-01-30 Thread Bronislav Klučka
Original Message Subject:Re: [FileAPI] createObjectURL isReusable proposal Date: Mon, 30 Jan 2012 17:51:55 +0100 From: Bronislav Klučka bronislav.klu...@bauglir.com To: Boris Zbarsky bzbar...@mit.edu On 30.1.2012 17:29, Boris Zbarsky wrote: On 1/30/12 11

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-30 Thread Ian Hickson
On Sat, 28 Jan 2012, Kyle Huey wrote: Why though? What stops UAs from accepting the relevant objects for .src properties? You don't necessarily have an object, e.g. if you're using innerHTML or document.write(). -- Ian Hickson U+1047E)\._.,--,'``.fL

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-30 Thread Bronislav Klučka
On 30.1.2012 17:51, Boris Zbarsky wrote: The same blob should have different URLs in different documents, no? All documents originated from the same application/session/same-origin? No. That's the point. Unless you want the lifetime of the Blob to immediately become while you have any

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-28 Thread Bronislav Klučka
On 28.1.2012 7:10, Darin Fisher wrote: On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson i...@hixie.ch mailto:i...@hixie.ch wrote: On Wed, 14 Dec 2011, Adrian Bateman wrote: [...] the first dereference of the URL revokes it. This means that you can do something like:

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-28 Thread Glenn Maynard
On Fri, Jan 27, 2012 at 6:14 PM, Glenn Maynard gl...@zewt.org wrote: Something else that needs to be defined: does xhr.open('GET', url) consume the URL, or does that only happen when xhr.send() is called? (I'm not looking for the answer here, just giving an example of something that needs to

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-28 Thread Kyle Huey
Why though? What stops UAs from accepting the relevant objects for .src properties? - Kyle On Sat, Jan 28, 2012 at 2:47 AM, Ian Hickson i...@hixie.ch wrote: On Sat, 28 Jan 2012, Kyle Huey wrote: On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher da...@chromium.org wrote: I'm not sure what

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-28 Thread Bronislav Klučka
It's reference issue img.src = URL.createObjectUrl(blob) means, that you cannot GC that blob, because URL is just text representation of reference. img.src = URL.createObjectUrl(blob, true) means, that you can GC that blob, because once URL is dereferenced, it will not be dereferenced again

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-27 Thread Arun Ranganathan
Glenn points out that the issues raised in this thread weren't totally taken to the mat. Once again, sorry for bad nesting in my response: We can certainly talk through some of these issues, though the amount of work we'd need to do doesn't go down. Our proposal is a small change

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-27 Thread Glenn Maynard
On Fri, Jan 27, 2012 at 11:57 AM, Arun Ranganathan aranganat...@mozilla.com wrote: I'd expect making this fully interoperable to be a complex problem. It makes fetch order significant, where it currently isn't. For example, if two images have their @src attribute set to a URL one after

Re: [FileAPI] createObjectURL isReusable proposal

2012-01-27 Thread Kyle Huey
On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher da...@chromium.org wrote: I'm not sure what a concrete proposal would look like. Maybe Element.URL.createObjectURL or just Element.createObjectURL? Wouldn't returning an object (which can be GCd) be a better solution? - Kyle

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-16 Thread Anne van Kesteren
On Wed, 14 Dec 2011 11:25:38 +0100, Jonas Sicking jo...@sicking.cc wrote: On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren ann...@opera.com wrote: I think we should solve this by assigning an object directly to attributes that take a URL. So instead you would get imgElement.src = blob

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-16 Thread Arun Ranganathan
Adrian, - Original Message - At TPAC [1,2] I described our proposal for adding an isReusable flag to createObjectURL. A common pattern we have seen is the need for a blob URL for a single use (for example, loading into an img element) and then revoking the URL. This requires a fair

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Anne van Kesteren
On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman adria...@microsoft.com wrote: At TPAC [1,2] I described our proposal for adding an isReusable flag to createObjectURL. A common pattern we have seen is the need for a blob URL for a single use (for example, loading into an img element) and then

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Jonas Sicking
On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman adria...@microsoft.com wrote: At TPAC [1,2] I described our proposal for adding an isReusable flag to createObjectURL. A common pattern we have seen is the need for a

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Tab Atkins Jr.
On Tue, Dec 13, 2011 at 4:52 PM, Adrian Bateman adria...@microsoft.com wrote: At TPAC [1,2] I described our proposal for adding an isReusable flag to createObjectURL. A common pattern we have seen is the need for a blob URL for a single use (for example, loading into an img element) and then

RE: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Adrian Bateman
On Wednesday, December 14, 2011 1:43 AM, Anne van Kesteren wrote: On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman adria...@microsoft.com wrote: This means that you can do something like: imgElement.src = URL.createObjectURL(blob,false) and not worry about having to call

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Jarred Nicholls
On Wed, Dec 14, 2011 at 11:31 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Dec 13, 2011 at 4:52 PM, Adrian Bateman adria...@microsoft.com wrote: At TPAC [1,2] I described our proposal for adding an isReusable flag to createObjectURL. A common pattern we have seen is the need for a

RE: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Adrian Bateman
On Wednesday, December 14, 2011 2:26 AM, Jonas Sicking wrote: On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman adria...@microsoft.com wrote: This means that you can do something like: imgElement.src =

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Glenn Maynard
On Wed, Dec 14, 2011 at 11:27 AM, Adrian Bateman adria...@microsoft.comwrote: On Wednesday, December 14, 2011 1:43 AM, Anne van Kesteren wrote: imgElement.src = blob 3. It's not very obvious what the lifetime of the blob should be if it goes out of scope after this happens. This, at

RE: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Adrian Bateman
On Wednesday, December 14, 2011 10:46 AM, Glenn Maynard wrote: We can certainly talk through some of these issues, though the amount of work we'd need to do doesn't go down. Our proposal is a small change to the lifetime management of the Blob URL and was relatively simple (for us) to

RE: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread James Graham
On Wed, 14 Dec 2011, Adrian Bateman wrote: On Wednesday, December 14, 2011 10:46 AM, Glenn Maynard wrote: We can certainly talk through some of these issues, though the amount of work we'd need to do doesn't go down. Our proposal is a small change to the lifetime management of the Blob URL

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Ian Hickson
On Wed, 14 Dec 2011, Adrian Bateman wrote: [...] the first dereference of the URL revokes it. This means that you can do something like: imgElement.src = URL.createObjectURL(blob,false) and not worry about having to call URL.revokeObjectURL to release the Blob. I think it's dangerous

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Glenn Maynard
On Wed, Dec 14, 2011 at 7:40 PM, Ian Hickson i...@hixie.ch wrote: I think the better solution is to have implementations make keeping object URLs defined be very cheap, so that nobody needs to ever release them. The problem isn't the cost of the URL mapping, it's the cost of keeping the

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Ian Hickson
On Wed, 14 Dec 2011, Glenn Maynard wrote: The problem isn't the cost of the URL mapping, it's the cost of keeping the backing Blob around. If you drag around Google Maps for a long time, and it used object URLs to load its tile images, it'd be very bad if the browser had to keep every

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Charles Pritchard
On 12/14/2011 4:55 PM, Ian Hickson wrote: On Wed, 14 Dec 2011, Glenn Maynard wrote: The problem isn't the cost of the URL mapping, it's the cost of keeping the backing Blob around. If you drag around Google Maps for a long time, and it used object URLs to load its tile images, it'd be very bad

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Ian Hickson
On Wed, 14 Dec 2011, Jonas Sicking wrote: On Wed, Dec 14, 2011 at 4:55 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 14 Dec 2011, Glenn Maynard wrote: The problem isn't the cost of the URL mapping, it's the cost of keeping the backing Blob around.  If you drag around Google Maps for a

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Charles Pritchard
On 12/14/2011 5:10 PM, Ian Hickson wrote: On Wed, 14 Dec 2011, Jonas Sicking wrote: On Wed, Dec 14, 2011 at 4:55 PM, Ian Hicksoni...@hixie.ch wrote: On Wed, 14 Dec 2011, Glenn Maynard wrote: The problem isn't the cost of the URL mapping, it's the cost of keeping the backing Blob around. If

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Jonas Sicking
On Wed, Dec 14, 2011 at 4:55 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 14 Dec 2011, Glenn Maynard wrote: The problem isn't the cost of the URL mapping, it's the cost of keeping the backing Blob around.  If you drag around Google Maps for a long time, and it used object URLs to load its

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-14 Thread Boris Zbarsky
On 12/14/11 7:55 PM, Ian Hickson wrote: Browsers do keep them around for the lifetime of the page, in their HTTP cache. Browsers limit the size of the HTTP cache and evict as needed. -Boris

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-13 Thread Charles Pritchard
I've seen the same pattern, though mysteriously, running a revoke in the same loop still allows the image to be loaded. I may have made a mistake in reading those source files or it may be a special quirk in the order of event loading. However this is approached, I think it should have firm

Re: [FileAPI] createObjectURL isReusable proposal

2011-12-13 Thread Simon Pieters
On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman adria...@microsoft.com wrote: At TPAC [1,2] I described our proposal for adding an isReusable flag to createObjectURL. A common pattern we have seen is the need for a blob URL for a single use (for example, loading into an img element) and