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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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.
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
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
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
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
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.
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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 =
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
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
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
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
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
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
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
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
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
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
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
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
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
70 matches
Mail list logo
