Re: [FileAPI] createObjectURL isReusable proposal
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 innerHTML return? If you copied such an image from a contentEditable section and pasted it lower down the same section, would it still have the image?). We could define that it returns an empty src attribute, which would break the copy/paste example. That's the same behavior you'd get with someone revoking the URL upon load anyway. That's what I want to do when assigning a MediaStream to a media element's src DOM attribute. https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html It seems to me to be the least bad option. Having DOM state that's not reflected in the serialized DOM (or copied by cloneNode()) is not good, but it's not new either. Form elements, canvases, and media elements already have similar issues. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: [FileAPI] createObjectURL isReusable proposal
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 benefits. There would be some really hard questions to answer, too (e.g. what would innerHTML return? If you copied such an image from a contentEditable section and pasted it lower down the same section, would it still have the image?). We could define that it returns an empty src attribute, which would break the copy/paste example. That's the same behavior you'd get with someone revoking the URL upon load anyway. That's what I want to do when assigning a MediaStream to a media element's src DOM attribute. https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html It seems to me to be the least bad option. Having DOM state that's not reflected in the serialized DOM (or copied by cloneNode()) is not good, but it's not new either. Form elements, canvases, and media elements already have similar issues. Which does not mean, that it does not matter... And the issue is different here, because all canvases behave the same, all forms behave the same, but here some images copies would produce actual image (http://) some would not (blob://). It would be much better to actually copy the Blob URL in src attribute and let it be dereferenced (it would either be succesfull or not, but it's based on programmer's design) Brona
RE: [FileAPI] createObjectURL isReusable proposal
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 to get an easy to use one-time-use
URL and avoid leaks in their applications. We've also noticed many
developers easily overlook the URL.revokeObjectURL API, thus failing to
realize they are pinning the resource behind the blob and further validating
the usefulness of this.
To address a few of the implementation questions that were raised in
this thread:
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?
We think a URL does not get consumed until the data has been accessed. As
XHR does not begin accessing the data until send has been called, we expect
Blob URLs to be no different. The URL should get revoked after xhr.send()
gets called. This is also what we've done in our implementation, and have not
noticed any confusion from developers.
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 my second impression is that in practice that error mode would
probably always result in the URL never being revoked and ending up
leaked, so it's probably best to free it anyway.)
Similar to the above case, the URL is not revoked until after the data is
accessed. If a URL is used from a different site of origin, the download fails
and the data is not accessed, thus the URL is not revoked. Developers can
notice this condition from the onerror handler for an img tag, where they
can revoke the URL if it did not resolve correctly.
What do you think of a global release mechanism? Such as
URL.revokeAllObjectUrls();
This wouldn't solve any of the problems previously listed in this thread,
and would only be useful as a convenience API. That said, I'd question
the trade-off of adding another API versus a developer writing their
own version of this, which should be fairly trivial.
We also think the spec should clarify what the expected behavior is for
a revoked URL when accounting for the image cache. The concept of
revoking URLs is to give the developer a way to say they are done with
the object. If a user agent still has the bits in memory, it should not be
in the business of blocking the URL from loading, even if it is revoked.
We’d like to see the spec updated to clarify the points listed above
and I'd be happy to help 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 24.2.2012 20:49, Arun Ranganathan wrote:
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 to explicitly
specify, that such URL is permanent should limit cases of I forgot
to release something somewhere... and I thing could be easier to
understant, that explicit request for pemranent = explicit release.
Would break current implementations, sure, but if we are
considering changes
So, having these URLs be oneTimeOnly by default itself has issues,
as Glenn (and Darin) point out:
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0377.h
tml
The existing model makes that scenario false by default, trading off
anything racy against culling strings.
We are back in an issue of someone using oneTimeOnly or permanent in
an inappropriate case. Programmers should be aware of what they are
doing.
I actually have no problem with current specification (rermanent as
default, expicit release), I'm just trying to prevent changes like
assigning object to string attribute (e.g. src), returning innerHTML
with empty string attribute (e.g. src)
My solution is that src should be modified to take both a string and a URL
object, which makes innerHTML behavior easier; I'm less sure of it taking Blob
directly.
-- A*
What change would it make compared to current scenario? URL as string or URL
as stringifiable object? What's the difference?
B.
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 my second impression is that in practice that error mode would probably always result in the URL never being revoked and ending up leaked, so it's probably best to free it anyway.) Similar to the above case, the URL is not revoked until after the data is accessed. If a URL is used from a different site of origin, the download fails and the data is not accessed, thus the URL is not revoked. Developers can notice this condition from the onerror handler for an img tag, where they can revoke the URL if it did not resolve correctly. I think they'd be very unlikely to notice, because the only side-effect is a reference leak wasting memory. The entire point of this API is to handle that collection for you; it should do it as consistently as can be managed. If you have to carefully watch onerror and release the URL in some cases, then the problem hasn't been solved at all. It makes more sense for the URL to be revoked upon entry to an API that uses the URL. The API, when it receives a URL, implicitly dereferences it to the underlying resource (retaining that reference), and revokes the URL. This always happens, even if the fetch fails for any reason (such as cross-origin restrictions), or even if the fetch never happens. An example of another problem this solves: if a UA obtains images on demand [1], it may never update the image data if the image is not actually in a document (and possibly not even if it is). If the URL is only released on access (fetch), then it would never be released. By releasing the URL immediately (in this case, on assignment to HTMLImageElement.src) and keeping an internal reference to the underlying resource (the blob), this problem doesn't happen, and the release of the URL happens at a consistent time, improving interoperability. [1] http://dev.w3.org/html5/spec/Overview.html#the-img-element What do you think of a global release mechanism? Such as URL.revokeAllObjectUrls(); This wouldn't solve any of the problems previously listed in this thread, and would only be useful as a convenience API. That said, I'd question the trade-off of adding another API versus a developer writing their own version of this, which should be fairly trivial. I think a revokeAll API would be very bad. It would allow completely unrelated pieces of code running on a site to interfere with one another; using an API like this would almost always be the wrong thing to do. We also think the spec should clarify what the expected behavior is for a revoked URL when accounting for the image cache. The concept of revoking URLs is to give the developer a way to say they are done with the object. If a user agent still has the bits in memory, it should not be in the business of blocking the URL from loading, even if it is revoked. If the HTMLImageElement has already performed the fetch and has the resulting data cached, and needs to access it again later (eg. because the decompressed data was discarded while it was off-screen), then yes. However, if you revoke a URL, then assign the URL to an image, that fetch should always fail, even if the blob happens to have not yet been GC'd. In that case, the bits are in memory, but the URL should always fail to load. -- Glenn Maynard
Re: [FileAPI] createObjectURL isReusable proposal
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 to get an easy to use one-time-use
URL and avoid leaks in their applications. We've also noticed many
developers easily overlook the URL.revokeObjectURL API, thus failing to
realize they are pinning the resource behind the blob and further validating
the usefulness of this.
To address a few of the implementation questions that were raised in
this thread:
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?
We think a URL does not get consumed until the data has been accessed. As
XHR does not begin accessing the data until send has been called, we expect
Blob URLs to be no different. The URL should get revoked after xhr.send()
gets called. This is also what we've done in our implementation, and have not
noticed any confusion from developers.
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 my second impression is that in practice that error mode would
probably always result in the URL never being revoked and ending up
leaked, so it's probably best to free it anyway.)
Similar to the above case, the URL is not revoked until after the data is
accessed. If a URL is used from a different site of origin, the download fails
and the data is not accessed, thus the URL is not revoked. Developers can
notice this condition from the onerror handler for an img tag, where they
can revoke the URL if it did not resolve correctly.
What do you think of a global release mechanism? Such as
URL.revokeAllObjectUrls();
This wouldn't solve any of the problems previously listed in this thread,
and would only be useful as a convenience API. That said, I'd question
the trade-off of adding another API versus a developer writing their
own version of this, which should be fairly trivial.
We also think the spec should clarify what the expected behavior is for
a revoked URL when accounting for the image cache. The concept of
revoking URLs is to give the developer a way to say they are done with
the object. If a user agent still has the bits in memory, it should not be
in the business of blocking the URL from loading, even if it is revoked.
We’d like to see the spec updated to clarify the points listed above
and I'd be happy to help with these changes in any way possible.
Thanks,
Feras
Hi,
are we talking about
http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html
?
because I still do not see, what have you solved...
Ok, instead of mutable string, you have an object, fine
but when you create this URL object out of Blob and assign that URL to
HTMLImageElement source, you are stuck again
1/ when will be such URL object be GC'd?
2/ when will underlying Blob be GC'd?
3/ what would @src of that image return? (or ancestor's innerHTML)?
Brona
Re: [FileAPI] createObjectURL isReusable proposal
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 permanent should limit cases of I forgot to release something somewhere... and I thing could be easier to understant, that explicit request for pemranent = explicit release. Would break current implementations, sure, but if we are considering changes So, having these URLs be oneTimeOnly by default itself has issues, as Glenn (and Darin) point out: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0377.html The existing model makes that scenario false by default, trading off anything racy against culling strings. I actually believe that strings for URLs may be short-lived, depending on how the URL API comes along [1] and depending on the discussion on extending interfaces. Both Chrome and Fx have create* and revoke* implemented now; the new options parameter adds some convenience which I think is worth it. -- A* [1] http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html B.
Re: [FileAPI] createObjectURL isReusable proposal
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 to explicitly specify, that such URL is permanent should limit cases of I forgot to release something somewhere... and I thing could be easier to understant, that explicit request for pemranent = explicit release. Would break current implementations, sure, but if we are considering changes So, having these URLs be oneTimeOnly by default itself has issues, as Glenn (and Darin) point out: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0377.html The existing model makes that scenario false by default, trading off anything racy against culling strings. We are back in an issue of someone using oneTimeOnly or permanent in an inappropriate case. Programmers should be aware of what they are doing. I actually have no problem with current specification (rermanent as default, expicit release), I'm just trying to prevent changes like assigning object to string attribute (e.g. src), returning innerHTML with empty string attribute (e.g. src) Brona.
Re: [FileAPI] createObjectURL isReusable proposal
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 to explicitly specify, that such URL is permanent should limit cases of I forgot to release something somewhere... and I thing could be easier to understant, that explicit request for pemranent = explicit release. Would break current implementations, sure, but if we are considering changes So, having these URLs be oneTimeOnly by default itself has issues, as Glenn (and Darin) point out: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0377.html The existing model makes that scenario false by default, trading off anything racy against culling strings. We are back in an issue of someone using oneTimeOnly or permanent in an inappropriate case. Programmers should be aware of what they are doing. I actually have no problem with current specification (rermanent as default, expicit release), I'm just trying to prevent changes like assigning object to string attribute (e.g. src), returning innerHTML with empty string attribute (e.g. src) My solution is that src should be modified to take both a string and a URL object, which makes innerHTML behavior easier; I'm less sure of it taking Blob directly. -- A*
Re: [FileAPI] createObjectURL isReusable proposal
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 in mitigating some of our fears. Hixie, is this possible? 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 innerHTML return? If you copied such an image from a contentEditable section and pasted it lower down the same section, would it still have the image?). We could define that it returns an empty src attribute, which would break the copy/paste example. That's the same behavior you'd get with someone revoking the URL upon load anyway. / Jonas The point of reusable Blob URL is the compatibility with regular URL, not having reusable URL would create unpleasant dichotomy in data manipulating... Brona
Re: [FileAPI] createObjectURL isReusable proposal
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 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 here would far outweigh the benefits. There would be some really hard questions to answer, too (e.g. what would innerHTML return? If you copied such an image from a contentEditable section and pasted it lower down the same section, would it still have the image?). We could define that it returns an empty src attribute, which would break the copy/paste example. That's the same behavior you'd get with someone revoking the URL upon load anyway. / Jonas The point of reusable Blob URL is the compatibility with regular URL, not having reusable URL would create unpleasant dichotomy in data manipulating... What do you think of a global release mechanism? Such as URL.revokeAllObjectUrls();
Re: [FileAPI] createObjectURL isReusable proposal
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 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 here would far outweigh the
benefits. There would be some really hard questions to answer, too
(e.g.
what would innerHTML return? If you copied such an image from a
contentEditable section and pasted it lower down the same section,
would
it still have the image?).
We could define that it returns an empty src attribute, which would
break the copy/paste example. That's the same behavior you'd get with
someone revoking the URL upon load anyway.
/ Jonas
The point of reusable Blob URL is the compatibility with regular URL,
not having reusable URL would create unpleasant dichotomy in data
manipulating...
What do you think of a global release mechanism? Such as
URL.revokeAllObjectUrls();
Sounds like very interesting idea... could clearly solve a lot of issues
here (load everything you want on load and the release it once) . So +1
But I would still leave some functionality for one image manipulation,
there still can be apps with mixed approach (some images with reusable
{application data}, some images without {application UI}), ore they may
not be even images here (images one time, but some file blob permanent).
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
permanent should limit cases of I forgot to release something
somewhere... and I thing could be easier to understant, that explicit
request for pemranent = explicit release. Would break current
implementations, sure, but if we are considering changes
B.
Re: [FileAPI] createObjectURL isReusable proposal
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 Maynard
Re: [FileAPI] createObjectURL isReusable proposal
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 manipulating... The point is avoiding the error-prone need to release resources by hand. -- Glenn Maynard Yes, that is why we have this thread, I was talking about Blob URL... I'm trying to find solution that would solve both (sure, I do not mind explicit release). I do not want solution where working with set of images would require to traverse through all images and somehow trying to determine whether images is regular URL or blob and go through 2 different branches. Suggestions like We could define that it returns an empty src attribute prohibits any additional working with such image... accessing such image tells me nothing... is such image Blob image? Is it new empty image? Brona
Re: [FileAPI] createObjectURL isReusable proposal
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 in mitigating some of our fears. Hixie, is this possible? 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 innerHTML return? If you copied such an image from a contentEditable section and pasted it lower down the same section, would it still have the image?). We could define that it returns an empty src attribute, which would break the copy/paste example. That's the same behavior you'd get with someone revoking the URL upon load anyway. / Jonas To the point of reusability of blob url and actual existence of such URL, we must also consider non-media usage: a element, window.open, etc. I do see the ideal of preparing data with JS and letting them be displayed/downloaded using those methods as quite usefull and intuitive. Brona
Re: [FileAPI] createObjectURL isReusable proposal
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, is this possible? 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 innerHTML return? If you copied such an image from a contentEditable section and pasted it lower down the same section, would it still have the image?). We could define that it returns an empty src attribute, which would break the copy/paste example. That's the same behavior you'd get with someone revoking the URL upon load anyway. / Jonas
Re: [FileAPI] createObjectURL isReusable proposal
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 would return string (regular URL, FileSystem APi URL) sometimes Blob... What would you do in case like this img.src = blob; div.appendChild(img); var s = div.innerHTML; div.innerHTML = ''; div.innerHTML = s; which would work with regular URL, would fail in your suggestion... This would fail just as badly with auto-releasing URLs. No approach so far makes this work (other than the explicit releasing that we're trying to give alternatives to). -- Glenn Maynard It's like talking to a wall sometimes DO NOT USE AUTO RELEASING URL IF YOU ARE GOING TO REUSE IMAGE :) I my approacha using cache-like blob URL did solve that :) Brona
Re: [FileAPI] createObjectURL isReusable proposal
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 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 in case like this img.src = blob; div.appendChild(img); var s = div.innerHTML; div.innerHTML = ''; div.innerHTML = s; which would work with regular URL, would fail in your suggestion... This would fail just as badly with auto-releasing URLs. No approach so far makes this work (other than the explicit releasing that we're trying to give alternatives to). -- Glenn Maynard It's like talking to a wall sometimes DO NOT USE AUTO RELEASING URL IF YOU ARE GOING TO REUSE IMAGE :) I my approacha using cache-like blob URL did solve that :) Brona -- Glenn Maynard
Re: [FileAPI] createObjectURL isReusable proposal
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. Hixie, is this possible? 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 innerHTML return? If you copied such an image from a contentEditable section and pasted it lower down the same section, would it still have the image?). My idea was that innerHTML and getAttribute and such would get back about:blob or some such. I think having the same object associated with two images should be fine, so copy pasting should probably work. about:blob is just for serialization purposes. -- Anne van Kesteren http://annevankesteren.nl/
Re: [FileAPI] createObjectURL isReusable proposal
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 be useful in mitigating some of our fears. Hixie, is this possible? 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 innerHTML return? If you copied such an image from a contentEditable section and pasted it lower down the same section, would it still have the image?). My idea was that innerHTML and getAttribute and such would get back about:blob or some such. I think having the same object associated with two images should be fine, so copy pasting should probably work. about:blob is just for serialization purposes. 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 in case like this img.src = blob; div.appendChild(img); var s = div.innerHTML; div.innerHTML = ''; div.innerHTML = s; which would work with regular URL, would fail in your suggestion... B.
Re: [FileAPI] createObjectURL isReusable proposal
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 in case like this img.src = blob; div.appendChild(img); var s = div.innerHTML; div.innerHTML = ''; div.innerHTML = s; which would work with regular URL, would fail in your suggestion... This would fail just as badly with auto-releasing URLs. No approach so far makes this work (other than the explicit releasing that we're trying to give alternatives to). -- Glenn Maynard
Re: [FileAPI] createObjectURL isReusable proposal
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 browser that discarded image data when the user toggles images off. It would mean that you couldn't clone the element and get the image data in the clone. It would mean that you couldn't read the image's .src URL and have anything useful. (From Darin Fisher) I share your concerns. This is enough reason to make me not want to support the one-shot flag. That said, I'm greatly bothered by how easily createObjectURL makes it to create web apps that accumulate mass amounts of unreleased and unused memory. Most examples gloss over revokeObjectURL entirely. I agree to the extent that minting Blob URLs for one-shot usage should be a non-default option, which is it is specified in the editor's draft (updated as of Feb 2 2012: http://dev.w3.org/2006/webapi/FileAPI/ ). I've also taken a crack at further examples, since I agree that the spec did have examples that gloss over revokeObjectURL... Further illustrative examples are welcome. URL.createObjectURL certainly can be misused, like other APIs on the web. That said here are a few ideas that may be well worth pursuing: 1. Note that the URL API, which we've extended in File API, was *originally* a Google proposal by Adam Barth [1]. We should breathe life into it. A fair number of things are blocked within WHATWG/HTML5 on it. And, we expressed some enthusiasm for it landing here [2]. It was supposed to give us a string-free way of working with URLs. If we did this API right, we could obviate URL.createObjectURL/URL.revokeObjectURL at *some* point. Could we pursue this within WHATWG or have this here? I'm ok with either option. 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? 3. Could we offer debugger + console guidance when URL.createObjectURL calls are made naively, without affiliated URL.revoke*? The idea of just letting these blobs accumulate until the document is destroyed is really unsatisfying. A growing number of apps have very long-lived main documents. What if createObjectURL were somehow scoped to an Element in the DOM (not just the Document itself)? For AJAX apps that are creating and tearing down DOM snippets frequently, if the blob URLs needed for a particular view were bound to elements in that view, then perhaps there would be a more natural cleansing of the blob URL registry. I'm not sure what a concrete proposal would look like. Maybe Element.URL.createObjectURL or just Element.createObjectURL? 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 this seems like a big change. 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. -- A* [1] https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=enpli=1 [2] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0819.html
Re: [FileAPI] createObjectURL isReusable proposal
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 here would far outweigh the benefits. There would be some really hard questions to answer, too (e.g. what would innerHTML return? If you copied such an image from a contentEditable section and pasted it lower down the same section, would it still have the image?). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [FileAPI] createObjectURL isReusable proposal
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. Hixie, is this possible?
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 innerHTML return? If you copied such an image from a
contentEditable section and pasted it lower down the same section, would
it still have the image?).
How about just a convenience method.
Blob.prototype.toString=function(){ return URL.createObjectURL(this);
};
Re: [FileAPI] createObjectURL isReusable proposal
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
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 this seems like a big change. If you want to remove middleman (object url), I'd prefer img.LoadFromBlob(blob) (or more generic LoadFromStream(aStream)). But that does not solve the issue of src attribute being string. B.
Re: [FileAPI] createObjectURL isReusable proposal
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 an object (which can be GCd) be a better solution? The whole point of the API is that we have an object but need a string (a URL). Hi, current pain here is that we have an string that can reference object and we have no idea when to release such object automatically (before document onunload). I do not know how to make my following suggestion in specification speech, but how about that use caching and regular URL-like approach: how would I implement it being browser developer: 1/ requiring of string identifier of Blob would make this blob part of caching mechanism, I would create temporary directory accessible by this document only and store blob data there e.g. under a file name abcd-efgh and return abcd-efgh as a blob URL (or use other mechanism that would allow direct conversion between string to file name). 2/ variable representing original blob could be subjected to regular GC, because I already have data copy to that URL, and those are not in memory (Or I could leave those data in memory for some time if assume I would need them soon (pseudo code): x = blob.url; some code; img.src = x;) 3/ any call requiring some blob url would be to resolved in application memory (if such blob exists there) or simply by checking application cache (it does not matter where do I get the URL, it can always be converted to one particular file name) 4/ on document unload, the cache would be cleared (to prevent problems with browser crash, I would probably create those temp directories based on document URL and clear the cache, every time such document is opened in it's first instance (if such cache would exists from previous time)) This user agent behavior may go beyond the scope of HTML specification, but we already have Offline web application cache... We could always leave the revokeObjectUrl call to simply delete content from cache... Brona
Re: [FileAPI] createObjectURL isReusable proposal
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 Element.createObjectURL? Wouldn't returning an object (which can be GCd) be a better solution? The whole point of the API is that we have an object but need a string (a URL). Hi, current pain here is that we have an string that can reference object and we have no idea when to release such object automatically (before document onunload). I do not know how to make my following suggestion in specification speech, but how about that use caching and regular URL-like approach: how would I implement it being browser developer: 1/ requiring of string identifier of Blob would make this blob part of caching mechanism, I would create temporary directory accessible by this document only and store blob data there e.g. under a file name abcd-efgh and return abcd-efgh as a blob URL (or use other mechanism that would allow direct conversion between string to file name). 2/ variable representing original blob could be subjected to regular GC, because I already have data copy to that URL, and those are not in memory (Or I could leave those data in memory for some time if assume I would need them soon (pseudo code): x = blob.url; some code; img.src = x;) 3/ any call requiring some blob url would be to resolved in application memory (if such blob exists there) or simply by checking application cache (it does not matter where do I get the URL, it can always be converted to one particular file name) 4/ on document unload, the cache would be cleared (to prevent problems with browser crash, I would probably create those temp directories based on document URL and clear the cache, every time such document is opened in it's first instance (if such cache would exists from previous time)) This user agent behavior may go beyond the scope of HTML specification, but we already have Offline web application cache... We could always leave the revokeObjectUrl call to simply delete content from cache... Brona BTW. I know It sounds a lot like something that can be done with FileSystem API, but I hope the ease and benefits for developers are clear here, FileSystem API would be overkill for this (and easier to implement for vendors without FileSystem API implemented yet) Brona
Re: [FileAPI] createObjectURL isReusable proposal
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. Maybe Element.URL.createObjectURL or just Element.createObjectURL? Wouldn't returning an object (which can be GCd) be a better solution? The whole point of the API is that we have an object but need a string (a URL). We could always leave the revokeObjectUrl call to simply delete content from cache... Brona BTW. I know It sounds a lot like something that can be done with FileSystem API, but I hope the ease and benefits for developers are clear here, FileSystem API would be overkill for this (and easier to implement for vendors without FileSystem API implemented yet) Brona Yes, revokeObjectURL would simply mark the content as dirty. Some other cache / trash cleanup takes care of the garbage. There's nothing in createObjectURL that says a Blob must be in RAM. For all intents, createObjectURL could put items into the Temporary FileSystem for a domain. The Chromium team has already lifted file size limitations on the temporary file system. That's with the understanding that items can be evicted at any time. However, createObjectURL specifies that an object may not be evicted until the page is navigated away from, or until revokeObjectURL is called. Persistence is typically limited to 5MB per domain. Or something like 10MB when localStorage is added to the mix. It seems like this is an interesting middle-ground. The battle is in the CSS-realm. With the img tag, we can simply hook into onerror. Within CSS, we are unaware as to whether our contested resource has been loaded. There are of course, iframe tricks, which are used for font loading. Lots of subtleties in this area. 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 they are with other APIs, if the limit has gone beyond what the UA is comfortable with. That's always useful for debugging/development -- when infinite loops are a normal part of the web experience. -Charles
Re: [FileAPI] createObjectURL isReusable proposal
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 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? The whole point of the API is that we have an object but need a string (a URL). We could always leave the revokeObjectUrl call to simply delete content from cache... Brona BTW. I know It sounds a lot like something that can be done with FileSystem API, but I hope the ease and benefits for developers are clear here, FileSystem API would be overkill for this (and easier to implement for vendors without FileSystem API implemented yet) Brona Yes, revokeObjectURL would simply mark the content as dirty. Some other cache / trash cleanup takes care of the garbage. There's nothing in createObjectURL that says a Blob must be in RAM. For all intents, createObjectURL could put items into the Temporary FileSystem for a domain. The Chromium team has already lifted file size limitations on the temporary file system. That's with the understanding that items can be evicted at any time. However, createObjectURL specifies that an object may not be evicted until the page is navigated away from, or until revokeObjectURL is called. Persistence is typically limited to 5MB per domain. Or something like 10MB when localStorage is added to the mix. I've mentioned FS API just as response to you can do it with FS API... This may have nothing to do with FS API on implementation level. It seems like this is an interesting middle-ground. The battle is in the CSS-realm. With the img tag, we can simply hook into onerror. Within CSS, we are unaware as to whether our contested resource has been loaded. There are of course, iframe tricks, which are used for font loading. Lots of subtleties in this area. So it would be stuck there until onunload, how many 1GB videos are there as source to CSS image? CSS+cache should be a regular deal when it comes to implementation I assume. 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 they are with other APIs, if the limit has gone beyond what the UA is comfortable with. That's always useful for debugging/development -- when infinite loops are a normal part of the web experience. Well how about 1GB video :D or 100 high resolution images? But as you say there's no reason, why desktop application (browser) should have any problem with it... And yes... there may be some disk space problems on rare cases, but such problems can appear in any regular usage of any program (well, there's simply no space left)... -Charles Brona
Re: [FileAPI] createObjectURL isReusable proposal
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 they are with other APIs, if the limit has gone beyond what the UA is comfortable with. That's always useful for debugging/development -- when infinite loops are a normal part of the web experience. Well how about 1GB video :D or 100 high resolution images? But as you say there's no reason, why desktop application (browser) should have any problem with it... And yes... there may be some disk space problems on rare cases, but such problems can appear in any regular usage of any program (well, there's simply no space left)... We're going to be treating that video as a media stream via Blob URL. Which is a good point -- it's going to be a Blob url of some sort but it is a special case. That 1GB video is not getting loaded into RAM all at once. A video blob is going to look like some cross of: http://www.w3.org/TR/streamproc/#media-element-extensions http://dev.w3.org/2011/webrtc/editor/webrtc.html http://dev.w3.org/2011/webrtc/editor/webrtc.html#blobcallback It's gonna be messy! Remember, we've got createObjectURL(File) as well, and the mess that can cause, as recently discussed. The underlying File data could disappear from the file system at any time That in mind, my focus is on img. And with 100 high res images, believe me: I'm using thumbnails. Not only that, I'm packing 8 thumbnails into each blob/file. So with 100 high res images, we're talking about 12 blobs, less than 60 megs. A lot less now that JPEG is widely supported for Canvas. -Charles
Re: [FileAPI] createObjectURL isReusable proposal
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 lifetime; the user can certainly be informed, as they are with other APIs, if the limit has gone beyond what the UA is comfortable with. That's always useful for debugging/development -- when infinite loops are a normal part of the web experience. Well how about 1GB video :D or 100 high resolution images? But as you say there's no reason, why desktop application (browser) should have any problem with it... And yes... there may be some disk space problems on rare cases, but such problems can appear in any regular usage of any program (well, there's simply no space left)... We're going to be treating that video as a media stream via Blob URL. Which is a good point -- it's going to be a Blob url of some sort but it is a special case. That 1GB video is not getting loaded into RAM all at once. A video blob is going to look like some cross of: http://www.w3.org/TR/streamproc/#media-element-extensions http://dev.w3.org/2011/webrtc/editor/webrtc.html http://dev.w3.org/2011/webrtc/editor/webrtc.html#blobcallback It's gonna be messy! Remember, we've got createObjectURL(File) as well, and the mess that can cause, as recently discussed. The underlying File data could disappear from the file system at any time That in mind, my focus is on img. And with 100 high res images, believe me: I'm using thumbnails. Not only that, I'm packing 8 thumbnails into each blob/file. So with 100 high res images, we're talking about 12 blobs, less than 60 megs. A lot less now that JPEG is widely supported for Canvas. -Charles I've already mentioned somewhere before I hope Blob would be descendant of stream, I have no problem with reducing this issue to more generic one (stream). 1GB video would not be loaded to RAM, why would it? I see no point of doing that, as long as one can seek in underlying stream, there's no point. I was referring to why an author should expect to stash 100MB of objects into createObjectURL, why not? if it's all cached on disc. author should not expect to have 3GB data in memory at once, but why would he/she? That is nothing one should be concern with. The underlying File data could disappear from the file system at any time Well.. they should not while they are managed by browser. And deleting the content by user (other application)? Well, I can go and simply delete all images on my server... and webpages would be displaying nothing for normal pages, server scripts working with such files could have problem. User can have image library desktop program displaying 20 images, then go, delete 15 of them from disk (while app is runnig) and trying to access those using this desktop program... problem for app. Special cases? Yes. Something new and unheard of? No... Programmer should be able to handle those. We can always have triad createObjectUrl, revokeObjectUrl and bool checkObjectUrl(DOMString aUrl). Brona
Re: [FileAPI] createObjectURL isReusable proposal
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 abandon the blob URL approach entirely and pursue something else (such as img.src = blob). Adding manual memory management to the web platform is a step backwards, IMO. - Kyle
Re: [FileAPI] createObjectURL isReusable proposal
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 is not simple reference taht you can count and garbaged by some logic, because you have no idea whether you are going to need underlying data or not. Sorry, this doesn't make sense. The HTMLImageElement simply retains a strong reference to the blob. -- Glenn Maynard
Re: [FileAPI] createObjectURL isReusable proposal
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 level as well, either URL reference or blob must be freed/nulled/whatever somewhere. This is not simple reference taht you can count and garbaged by some logic, because you have no idea whether you are going to need underlying data or not. Sorry, this doesn't make sense. The HTMLImageElement simply retains a strong reference to the blob. -- Glenn Maynard 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 propose other attribute? What would then be in src? What if I change that blob? Should image change immediately as well? What if this was video playing? Brona
Re: [FileAPI] createObjectURL isReusable proposal
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 propose other attribute? What would then be in src?
img1 = document.getElementById(my-image);
img1.src = myBlob;
assert(img1.src == myBlob);
img2 = document.getElementById(my-other-image);
img2.src = img1.src; // works as always; you can't do this with
auto-releasing object URLs
This is trivially simple for users to understand, and doesn't raise any of
the hard issues that auto-releasing object URLs do.
The main question is innerHTML/outerHTML, where the object can't be
represented; it would need to be exposed as a placeholder string.
(However, auto-release object URLs break many uses of these too, since the
URL is no longer valid!) It means you can't use this with most approaches
to HTML templating in JS, which is annoying. That said, there have been
various suggestions for augmenting HTML-like templating, and it could be
made possible, eg.:
document.createTemplatedElement(img width=${width} height=${height}
src=${myImage}, {myImage: myBlob, width: 800, height: 600});
What if I change that blob? Should image change immediately as well? What
if this was video playing?
You can't change a blob.
--
Glenn Maynard
Re: [FileAPI] createObjectURL isReusable proposal
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 managing images (lightboxes) would have to
consider, what does src mean? Or do you propose other attribute?
What would then be in src?
img1 = document.getElementById(my-image);
img1.src = myBlob;
assert(img1.src == myBlob);
img2 = document.getElementById(my-other-image);
img2.src = img1.src; // works as always; you can't do this with
auto-releasing object URLs
If you are worried about autoreleasing URLs in such cases, do not use
them! Why on Earth would you use autoreleasing URLs when you are using
the URL twice?
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 (destroying the image)
This is trivially simple for users to understand, and doesn't raise
any of the hard issues that auto-releasing object URLs do.
We are introducing more and more complex technologies, JS is no longer
to move stuff on page, one have to learn what he/she is doing and why.
The main question is innerHTML/outerHTML, where the object can't be
represented; it would need to be exposed as a placeholder string.
(However, auto-release object URLs break many uses of these too,
since the URL is no longer valid!)
No problem with permanent Blob URL at all
It means you can't use this with most approaches to HTML templating in
JS, which is annoying. That said, there have been various suggestions
for augmenting HTML-like templating, and it could be made possible, eg.:
document.createTemplatedElement(img width=${width} height=${height}
src=${myImage}, {myImage: myBlob, width: 800, height: 600});
dtto
and again
img1 = document.getElementById(my-image);
img1.src = myBlob;
what should img1.src return? Blob? really? after 20 year you want to
change it?
BTW why is there no Blob.URL anymore?
Brona
Re: [FileAPI] createObjectURL isReusable proposal
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 (destroying the image) No, it won't. As currently specced it will be released when the document goes away or when the url created via createObjectURL is manually revoked. That's precisely the problem. -Boris 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? 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... Brona
Re: [FileAPI] createObjectURL isReusable proposal
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 URL.createObjectUrl is in syntax. The semantics are the same ... and the leak still exists. - Kyle
Re: [FileAPI] createObjectURL isReusable proposal
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: window.myStash = URL.createObjectUrl(blob).split(); img.src = window.myStash.join(); // much later one otherImg.src = window.myStash.join(); This is a simple case, of course. The url could be stored in all sorts of other ways, because strings are very very mungable from JS. On the other hand, if elements can be given blob objects directly then the ownership model is completely clear to both the UA and the developer. so just a line URL.createObjectUrl(blob) creates a memory leak? Heh? For the lifetime of the document, yes. Though I suspect that if you call it again on the same blob there is no more leak than before. Which brink me to my previous question, what happened to Blob.URL? Just brink it back and this whole conversation can go away... The same blob should have different URLs in different documents, no? -Boris
Re: [FileAPI] createObjectURL isReusable proposal
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 someone has a reference it. Consider this: window.myStash = URL.createObjectUrl(blob).split(); img.src = window.myStash.join(); // much later one otherImg.src = window.myStash.join(); This is a simple case, of course. The url could be stored in all sorts of other ways, because strings are very very mungable from JS. On the other hand, if elements can be given blob objects directly then the ownership model is completely clear to both the UA and the developer. so just a line URL.createObjectUrl(blob) creates a memory leak? Heh? For the lifetime of the document, yes. Though I suspect that if you call it again on the same blob there is no more leak than before. 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... Which brink me to my previous question, what happened to Blob.URL? Just brink it back and this whole conversation can go away... The same blob should have different URLs in different documents, no? All documents originated from the same application/session/same-origin? I'd prefer the same URL ( e.g. just passing string using window.postMessage) . What if I move image element from one document to another (from top window to iframe) should it have no identifiable underlying data? I don't like that -Boris Brona
Fwd: Re: [FileAPI] createObjectURL isReusable proposal
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: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: window.myStash = URL.createObjectUrl(blob).split(); img.src = window.myStash.join(); // much later one otherImg.src = window.myStash.join(); This is a simple case, of course. The url could be stored in all sorts of other ways, because strings are very very mungable from JS. Sorry, of course I understand, we do not only have arbitrary string created by this method, but there can be Blob itself hanging in memory... well 3 options are here 1/ leave URL revokable (affecting blob) 2/ create something like Blob.dispose() (affecting URL) 3/ assign blob to media element (but I do not like the SRC attribute for that, and it causes issues with HTML source text) nice :) Brona
Re: [FileAPI] createObjectURL isReusable proposal
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 documents from this origin open. Or in more concrete terms, while you Google Reader is open, no Blobs on any google.com page that have had urls created for them would ever be collected. That seems very bad. I'd prefer the same URL ( e.g. just passing string using window.postMessage) . What if I move image element from one document to another (from top window to iframe) should it have no identifiable underlying data? I don't like that It's not great; the alternatives just seem worse. -Boris This is just bad... I could go for same origin is problem, but same original document (other document spawned by this document based on same origin - iframe, window.open, etc. respecting same origin policy). Because this is just bad... It's like every time one might think hey, I can create application without web server, there's specification laughing and throwing bricks at you. Again, the easiest way to handle that is to simply upload that image to server using AJAX, let URL be returned (regular http://) and no problem at all... There's been great progress in all regarding FileApi, but being able to work with the result is just pain... Is there any way we can come up with any conclusion here? I'm fine with current one, though I understand that explicit memory management is little bit odd for some people. I really do think that while assigning blob to src attribute can make some some on setter level (just some sense), it makes no sense on getter level (when what you need to work with is text, like we everybody is used to for 2 decades and because it is HTML attribute, it must have some string representation). Brona
Re: [FileAPI] createObjectURL isReusable proposal
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: imgElement.src = URL.createObjectURL(blob,false) and not worry about having to call URL.revokeObjectURL to release the Blob. 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 browser that discarded image data when the user toggles images off. It would mean that you couldn't clone the element and get the image data in the clone. It would mean that you couldn't read the image's .src URL and have anything useful. I share your concerns. This is enough reason to make me not want to support the one-shot flag. That said, I'm greatly bothered by how easily createObjectURL makes it to create web apps that accumulate mass amounts of unreleased and unused memory. Most examples gloss over revokeObjectURL entirely. The idea of just letting these blobs accumulate until the document is destroyed is really unsatisfying. A growing number of apps have very long-lived main documents. What if createObjectURL were somehow scoped to an Element in the DOM (not just the Document itself)? For AJAX apps that are creating and tearing down DOM snippets frequently, if the blob URLs needed for a particular view were bound to elements in that view, then perhaps there would be a more natural cleansing of the blob URL registry. I'm not sure what a concrete proposal would look like. Maybe Element.URL.createObjectURL or just Element.createObjectURL? -Darin 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. Those concerns would make sense if this was the only solution, but one can always stick with create/revoke approach, if you know, you do not (and most likely will not) need URL, just one-time method, if you know you would need it, or it is highly possible, use create/revoke. If you use one-time method but will try to reuse such URL, you've made programming error, this is not language/API fault. Brona
Re: [FileAPI] createObjectURL isReusable proposal
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 be clearly defined.)
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 my second
impression is that in practice that error mode would probably always result
in the URL never being revoked and ending up leaked, so it's probably best
to free it anyway.)
--
Glenn Maynard
Re: [FileAPI] createObjectURL isReusable proposal
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 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? The whole point of the API is that we have an object but need a string (a URL). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [FileAPI] createObjectURL isReusable proposal
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 (BLOB data are used just here) and unless there is another reference to such blob, GC can get rid of it img.src = blob; tells nothing about possible access to underlying data using URL identifier Brona On 29.1.2012 4:31, Kyle Huey wrote: 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 mailto: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 mailto: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? The whole point of the API is that we have an object but need a string (a URL).
Re: [FileAPI] createObjectURL isReusable proposal
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 to the lifetime management of the Blob URL and was relatively simple (for us) to implement. In our experience, createObjectURL is a good broker in web developers minds for switching from object to URL space. 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 the other, what guarantees which one succeeds (presumably the first) and which fails (due to the first releasing the URL)? The order in which synchronous sections after await a stable state are run isn't specified. Combining different APIs which do similar things (eg. asynchronous XHR and HTMLMediaElement's resource selection algorithm) would compound the problem. Adding this API increases the likelihood of a race condition; it may not do to simply go all Highlander on this problem (There can be only one!) and leave it to implementations. Is this an argument to *do away* with the dictionary key for oneTimeOnly or to make another spec modification that explicitly calls for a strong reference during HTMLMediaElement's resource selection algorithm (is such an ask even possible)? You point out later on [1] that this can also be true of revoke* for async XHR. Another possible problem, depending on where the blob release takes place: if the UA doesn't support images, update the image data for HTMLImageElement terminates at step 4; it would need to be careful to still release the blob URL when terminating before the fetch. This can be another spec detail for UAs that don't support images; in other words, should we have a section on revoke* (advice to implementors)? This would probably have effects across a lot of specs, and couldn't be neatly tucked away in one place (such as inside the resource fetch algorithm); and it might force every API that performs fetches to worry about creating race conditions with other APIs. Assigning the blob directly would still affect various specs, but it would be less likely to lead to blob leakage and subtle, possibly racy interop failures. I'm not sure we're at a place where we can contemplate assigning the Blob directly yet. I'm not sure how to spec against racy interop failures, other than list them as caveats. Choices seem to be: 1. Agree that it's a problem, call it out in the spec as best as possible, and move on (add the dictionary). 2. Agree that it's WAY too big of a problem, and eliminate the dictionary. But we'd have to add more thought to revoke* in the spec. -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1541.html
Re: [FileAPI] createObjectURL isReusable proposal
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 the other, what guarantees which one succeeds (presumably the first)
and which fails (due to the first releasing the URL)? The order in which
synchronous sections after await a stable state are run isn't specified.
Combining different APIs which do similar things (eg. asynchronous XHR and
HTMLMediaElement's resource selection algorithm) would compound the problem.
Adding this API increases the likelihood of a race condition; it may not
do to simply go all Highlander on this problem (There can be only one!)
and leave it to implementations. Is this an argument to *do away* with the
dictionary key for oneTimeOnly or to make another spec modification that
explicitly calls for a strong reference during HTMLMediaElement's resource
selection algorithm (is such an ask even possible)?
I'm only arguing that adding an API that's racy by design should be
scrutinized very carefully.
I think to avoid raciness, the URL should be consumed *synchronously*
when it's used, even if the associated fetch is asynchronous. This avoids
the problem of using a URL with multiple, unrelated APIs which consume the
URL from different task queues, where the order of the queued tasks aren't
defined relative to each other.
You point out later on [1] that this can also be true of revoke* for async
XHR.
Right. I didn't mean it as precedent to not concern ourselves with races,
though, just an acknowledgement that the platform isn't completely perfect
in this.
Another possible problem, depending on where the blob release takes place:
if the UA doesn't support images, update the image data for
HTMLImageElement terminates at step 4; it would need to be careful to still
release the blob URL when terminating before the fetch.
This can be another spec detail for UAs that don't support images; in
other words, should we have a section on revoke* (advice to implementors)?
I think it'd be best to have the point at which the URL is considered
consumed to be a clear, explicit step in every algorithm that can consume a
single-use URL. In other words, the point where the algorithm takes a
reference to the resource underneath the URL and revokes the object URL. I
don't know the best way to do that, and I don't know how many algorithms
would be affected. Presumably, a concise, reusable wording would need to
be found that could be plugged into other specs as easily as possible.
For example, img.src = tempUrl1; img.src = tempUrl2 should be required by
spec to always consume both URLs, even if the first fetch didn't complete
before the second assignment happened. (It would probably happen early in
the update the image data algorithm.)
A more complex, multi-API example: img.src = tempUrl1; xhr.open('GET',
tempUrl1, false); xhr.send();. That sets an image to the URL, then
immediately does a synchronous XHR on the same URL. If the first
assignment synchronously consumes the URL, then the behavior is always
defined. The XHR get will always fail, even if the fetch associated with
the img.src assignment hasn't yet happened, because the synchronous part
(update the image data) consumes the URL.
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 be clearly defined.)
--
Glenn Maynard
Re: [FileAPI] createObjectURL isReusable proposal
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
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 The problem is that we have tons of APIs that deal with URLs in the form of strings. Not least the CSSOM which uses a lot of string concatenation. So we'd have to sign up for a very big task of changing all of these APIs so that they work with objects instead of strings. Speccing and getting that implemented will take a considerable amount of time. I do think that is something that we should do and as I understand it this is what developers want as well. In addition, as Charles Pritchard said elsewhere in this thread: Using automatic revocation with CSS makes no sense at all, I think the use here is simply for one-time img.src setters. There's also things like .innerHTML which people often prefer over using the direct DOM API. Some of this is likely due to the pain that the DOM-API is, but I suspect even with a perfect DOM API we'd still see a lot of string usage due to it's ease of use. So I'm not convinced that the value/cost ratio of this proposed solution is high enough. The proposed API is significantly more complex for what is likely to be the common case and is also more complex than the basic usage of createObjectURL(). So only if you are an extremely competent programmer you will do the right thing here. I think that is very bad design. -- Anne van Kesteren http://annevankesteren.nl/
Re: [FileAPI] createObjectURL isReusable proposal
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 amount of boilerplate code to handle the load/error events. I think we should work with the assumption that revoke* won't be called often. Do you think lifetime conditions are insufficient here in cases where revoke* is not called? Is the additional boolean something that the developers you've polled say adds clarity over the lifetime conditions? I agree that create* / revoke* is a fair amount of boilerplate for very simple uses. But I'm lukewarm about this proposal as it stands, since I'm not totally sure what it buys us really, since both models lend themselves to abuse of the default (not calling revoke* or relying on the default value of the new param). If we go this route, I'm inclined to agree that we don't really want a boolean, but something like an options. -- A*
Re: [FileAPI] createObjectURL isReusable proposal
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 revoking the URL. This requires a fair amount of boilerplate code to handle the load/error events. createObjectURL is modified as follows: static DOMString createObjectURL(Blob blob, [optional] bool isReusable); The value of isReusable defaults to true if it is not supplied and this results in the behaviour documented for File API today. However, if you supply false for the flag then 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 we should solve this by assigning an object directly to attributes that take a URL. So instead you would get imgElement.src = blob which is much cleaner I think. (The content attribute would then be set to about:object-url or some such.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [FileAPI] createObjectURL isReusable proposal
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 blob URL for a single use (for example, loading into an img element) and then revoking the URL. This requires a fair amount of boilerplate code to handle the load/error events. createObjectURL is modified as follows: static DOMString createObjectURL(Blob blob, [optional] bool isReusable); The value of isReusable defaults to true if it is not supplied and this results in the behaviour documented for File API today. However, if you supply false for the flag then 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 we should solve this by assigning an object directly to attributes that take a URL. So instead you would get imgElement.src = blob which is much cleaner I think. (The content attribute would then be set to about:object-url or some such.) The problem is that we have tons of APIs that deal with URLs in the form of strings. Not least the CSSOM which uses a lot of string concatenation. So we'd have to sign up for a very big task of changing all of these APIs so that they work with objects instead of strings. Speccing and getting that implemented will take a considerable amount of time. There's also things like .innerHTML which people often prefer over using the direct DOM API. Some of this is likely due to the pain that the DOM-API is, but I suspect even with a perfect DOM API we'd still see a lot of string usage due to it's ease of use. So I'm not convinced that the value/cost ratio of this proposed solution is high enough. / Jonas
Re: [FileAPI] createObjectURL isReusable proposal
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
revoking the URL. This requires a fair amount of boilerplate code to
handle the load/error events.
createObjectURL is modified as follows:
static DOMString createObjectURL(Blob blob, [optional] bool isReusable);
The value of isReusable defaults to true if it is not supplied and this
results in the behaviour documented for File API today. However, if you
supply false for the flag then 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.
We have implemented this in experimental form in IE10 preview builds and
it works well. There seemed to be a fair amount of support at TPAC and we're
hoping this will be adopted in the File API spec.
Thanks,
Adrian.
[1] http://www.w3.org/2011/11/01-webapps-minutes.html#item02
[2] http://pages.adrianba.net/w3c/FilesAndStreams.pdf
I object to adding boolean flag arguments to any new APIs. They're a
blight on the platform. Further, baking non-essential arguments into
the argument list almost guarantees confusion down the line when
*more* options are added.
Please add this as an options object with a reusable property, like
createObjectURL(blob, {reusable:false}) (or whatever name gets
decided on, like single-use).
~TJ
RE: [FileAPI] createObjectURL isReusable proposal
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 URL.revokeObjectURL to release the Blob. 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 which is much cleaner I think. (The content attribute would then be set to about:object-url or some such.) I've seen this discussed before. I'm not overly enamoured with this approach. Here are some of the reasons: 1. We have to change these properties to be of type 'any' and it's not obvious what impact that will have. 2. It involves making substantial changes to code flows that source content, which at least for us, would mean a fair amount of code churn. 3. It's not very obvious what the lifetime of the blob should be if it goes out of scope after this happens. 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 implement. In our experience, createObjectURL is a good broker in web developers minds for switching from object to URL space. Cheers, Adrian.
Re: [FileAPI] createObjectURL isReusable proposal
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 blob URL
for a single use (for example, loading into an img element) and then
revoking the URL. This requires a fair amount of boilerplate code to
handle the load/error events.
createObjectURL is modified as follows:
static DOMString createObjectURL(Blob blob, [optional] bool isReusable);
The value of isReusable defaults to true if it is not supplied and this
results in the behaviour documented for File API today. However, if you
supply false for the flag then 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.
We have implemented this in experimental form in IE10 preview builds and
it works well. There seemed to be a fair amount of support at TPAC and
we're
hoping this will be adopted in the File API spec.
Thanks,
Adrian.
[1] http://www.w3.org/2011/11/01-webapps-minutes.html#item02
[2] http://pages.adrianba.net/w3c/FilesAndStreams.pdf
I object to adding boolean flag arguments to any new APIs. They're a
blight on the platform. Further, baking non-essential arguments into
the argument list almost guarantees confusion down the line when
*more* options are added.
Please add this as an options object with a reusable property, like
createObjectURL(blob, {reusable:false}) (or whatever name gets
decided on, like single-use).
~TJ
I completely agree. Boolean traps are a serious problem for intuitiveness
and hamstrings the ability to add more options later that don't further
confuse the situation.
RE: [FileAPI] createObjectURL isReusable proposal
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 = URL.createObjectURL(blob,false) and not worry about having to call URL.revokeObjectURL to release the Blob. 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 which is much cleaner I think. (The content attribute would then be set to about:object-url or some such.) The problem is that we have tons of APIs that deal with URLs in the form of strings. Not least the CSSOM which uses a lot of string concatenation. So we'd have to sign up for a very big task of changing all of these APIs so that they work with objects instead of strings. Speccing and getting that implemented will take a considerable amount of time. There's also things like .innerHTML which people often prefer over using the direct DOM API. Some of this is likely due to the pain that the DOM-API is, but I suspect even with a perfect DOM API we'd still see a lot of string usage due to it's ease of use. So I'm not convinced that the value/cost ratio of this proposed solution is high enough. I agree - I forgot to mention the CSSOM issue in my previous reply but it is something we've thought about too. Adrian.
Re: [FileAPI] createObjectURL isReusable proposal
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 least, seems straightforward: the object (eg. imgElement) would hold a strong reference to the blob. It's also nice that this would still work: imgElement1.src = blob; ... imgElement2.src = imgElement1.src; // we don't know anything about imgElement1 here which wouldn't work with self-releasing object URLs. 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 implement. In our experience, createObjectURL is a good broker in web developers minds for switching from object to URL space. 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 the other, what guarantees which one succeeds (presumably the first) and which fails (due to the first releasing the URL)? The order in which synchronous sections after await a stable state are run isn't specified. Combining different APIs which do similar things (eg. asynchronous XHR and HTMLMediaElement's resource selection algorithm) would compound the problem. Another possible problem, depending on where the blob release takes place: if the UA doesn't support images, update the image data for HTMLImageElement terminates at step 4; it would need to be careful to still release the blob URL when terminating before the fetch. This would probably have effects across a lot of specs, and couldn't be neatly tucked away in one place (such as inside the resource fetch algorithm); and it might force every API that performs fetches to worry about creating race conditions with other APIs. Assigning the blob directly would still affect various specs, but it would be less likely to lead to blob leakage and subtle, possibly racy interop failures. -- Glenn Maynard
RE: [FileAPI] createObjectURL isReusable proposal
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 implement. In our experience, createObjectURL is a good broker in web developers minds for switching from object to URL space. 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 the other, what guarantees which one succeeds (presumably the first) and which fails (due to the first releasing the URL)? The order in which synchronous sections after await a stable state are run isn't specified. Combining different APIs which do similar things (eg. asynchronous XHR and HTMLMediaElement's resource selection algorithm) would compound the problem. Another possible problem, depending on where the blob release takes place: if the UA doesn't support images, update the image data for HTMLImageElement terminates at step 4; it would need to be careful to still release the blob URL when terminating before the fetch. This would probably have effects across a lot of specs, and couldn't be neatly tucked away in one place (such as inside the resource fetch algorithm); and it might force every API that performs fetches to worry about creating race conditions with other APIs. Assigning the blob directly would still affect various specs, but it would be less likely to lead to blob leakage and subtle, possibly racy interop failures. I don't think we need interop for race conditions. Trying to use a one-time URL twice is supposed to go wrong and I don't think it necessarily has to go wrong in exactly the same way in all browsers. You might have the same problem based on when you call revokeObjectURL in applications today. Adrian.
RE: [FileAPI] createObjectURL isReusable proposal
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 and was relatively simple (for us) to implement. In our experience, createObjectURL is a good broker in web developers minds for switching from object to URL space. 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 the other, what guarantees which one succeeds (presumably the first) and which fails (due to the first releasing the URL)? The order in which synchronous sections after await a stable state are run isn't specified. Combining different APIs which do similar things (eg. asynchronous XHR and HTMLMediaElement's resource selection algorithm) would compound the problem. Another possible problem, depending on where the blob release takes place: if the UA doesn't support images, update the image data for HTMLImageElement terminates at step 4; it would need to be careful to still release the blob URL when terminating before the fetch. This would probably have effects across a lot of specs, and couldn't be neatly tucked away in one place (such as inside the resource fetch algorithm); and it might force every API that performs fetches to worry about creating race conditions with other APIs. Assigning the blob directly would still affect various specs, but it would be less likely to lead to blob leakage and subtle, possibly racy interop failures. I don't think we need interop for race conditions. Trying to use a one-time URL twice is supposed to go wrong and I don't think it necessarily has to go wrong in exactly the same way in all browsers. You might have the same problem based on when you call revokeObjectURL in applications today. Historically failure to interop on things that were supposed to go wrong hasn't resulted in people avoiding those things but instead has resulted in them depending on the specific behaviour of one implementation.
Re: [FileAPI] createObjectURL isReusable proposal
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 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 browser that discarded image data when the user toggles images off. It would mean that you couldn't clone the element and get the image data in the clone. It would mean that you couldn't read the image's .src URL and have anything useful. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [FileAPI] createObjectURL isReusable proposal
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 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 tile graphic around for the lifetime of the page. (Being able to splash Blobs to disk makes this less pressing, at least on desktops, but the problem is still there.) -- Glenn Maynard
Re: [FileAPI] createObjectURL isReusable proposal
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 tile graphic around for the lifetime of the page. Browsers do keep them around for the lifetime of the page, in their HTTP cache. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [FileAPI] createObjectURL isReusable proposal
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
if the browser had to keep every tile graphic around for the lifetime of
the page.
Browsers do keep them around for the lifetime of the page, in their HTTP
cache.
I doubt that. I can't even get stable results for scrip.src = '#' or
new Worker('#'); Sometimes it fetches, sometimes it's cached.
Re: [FileAPI] createObjectURL isReusable proposal
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 long time, and it used object URLs to load its tile images, it'd be very bad if the browser had to keep every tile graphic around for the lifetime of the page. Browsers do keep them around for the lifetime of the page, in their HTTP cache. This isn't true at least for Firefox. We allow resources to be kicked out of the HTTP cache even if the page that originally caused the resource to be loaded is still being used. I guess. For pages that are dealing with bazillions of images then it makes sense to have the page discard the blobs once they're no longer in use. But I am very skeptical about an API that makes that happen automatically, because it really makes the API as a whole quite brittle. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [FileAPI] createObjectURL isReusable proposal
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 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 tile graphic around for the
lifetime of the page.
Browsers do keep them around for the lifetime of the page, in their
HTTP cache.
This isn't true at least for Firefox. We allow resources to be kicked
out of the HTTP cache even if the page that originally caused the
resource to be loaded is still being used.
I guess. For pages that are dealing with bazillions of images then it
makes sense to have the page discard the blobs once they're no longer in
use. But I am very skeptical about an API that makes that happen
automatically, because it really makes the API as a whole quite brittle.
Seems to me that onerror hooks are handy in this case, but that does
create more work.
I've typically used setAttribute('data-bloburl', url) when working with
images, running revoke prior to doing a new setAttribute.
I've not started using onerror: I could certainly see using onerror and
some other internal pointer, setAttribute('data-position', posinset) to
refresh a blob url, recovering it when it breaks.
That doesn't help the CSS case, however. Using automatic revocation
with CSS makes no sense at all, I think the use here is simply for
one-time img.src setters.
I also think that it can be accomplished without the Boolean, by
ensuring that revoke does not take effect until the end of the event loop.
-Charles
Re: [FileAPI] createObjectURL isReusable proposal
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 tile images, it'd be very bad if the browser had to keep every tile graphic around for the lifetime of the page. Browsers do keep them around for the lifetime of the page, in their HTTP cache. This isn't true at least for Firefox. We allow resources to be kicked out of the HTTP cache even if the page that originally caused the resource to be loaded is still being used. I can't speak for other browsers of course. / Jonas
Re: [FileAPI] createObjectURL isReusable proposal
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
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 roots in the operation of the event loop. On 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 revoking the URL. This requires a fair amount of boilerplate code to handle the load/error events. createObjectURL is modified as follows: static DOMString createObjectURL(Blob blob, [optional] bool isReusable); The value of isReusable defaults to true if it is not supplied and this results in the behaviour documented for File API today. However, if you supply false for the flag then 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. We have implemented this in experimental form in IE10 preview builds and it works well. There seemed to be a fair amount of support at TPAC and we're hoping this will be adopted in the File API spec. Thanks, Adrian. [1] http://www.w3.org/2011/11/01-webapps-minutes.html#item02 [2] http://pages.adrianba.net/w3c/FilesAndStreams.pdf
Re: [FileAPI] createObjectURL isReusable proposal
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 revoking the URL. This requires a fair amount of boilerplate code to handle the load/error events. createObjectURL is modified as follows: static DOMString createObjectURL(Blob blob, [optional] bool isReusable); The value of isReusable defaults to true if it is not supplied and this results in the behaviour documented for File API today. However, if you supply false for the flag then the first dereference of the URL revokes it. Could the argument have inverted semantics? Optional arguments that default to true are a bit confusing. Usually omitted boolean arguments default to false. 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. We have implemented this in experimental form in IE10 preview builds and it works well. There seemed to be a fair amount of support at TPAC and we're hoping this will be adopted in the File API spec. Thanks, Adrian. [1] http://www.w3.org/2011/11/01-webapps-minutes.html#item02 [2] http://pages.adrianba.net/w3c/FilesAndStreams.pdf -- Simon Pieters Opera Software
