[FileAPI] createObjectURL isReusable proposal

[Adrian Bateman]

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  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

[Charles Pritchard]

I've seen the same pattern, though mysteriously, running a revoke in the same 
loop still allows the image to be loaded. I may have made a mistake in reading 
those source files or it may be a special quirk in the order of event loading.

However this is approached, I think it should have firm roots in the operation 
of the event loop.



On Dec 13, 2011, at 4:52 PM, Adrian Bateman  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  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

[Simon Pieters]

On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman  
 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  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

Re: [FileAPI] createObjectURL isReusable proposal

[Anne van Kesteren]

On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman  
 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  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

[Jonas Sicking]

On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren  wrote:
> On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman 
> 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  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

[Adrian Bateman]

On Tuesday, December 13, 2011 10:41 PM, Simon Pieters wrote:
> On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman
>  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  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.

We could obviously reverse the check - the approach we chose was based on
feedback for what people felt was intuitive. It's a subjective decision,
of course. There are other places in the web platform with defaults to
true. I'm not wedded to one way or the other but for the code we've
written so far, which we could change.

Cheers,

Adrian.

Re: [FileAPI] createObjectURL isReusable proposal

[Tab Atkins Jr.]

On Tue, Dec 13, 2011 at 4:52 PM, Adrian Bateman  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  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

[Adrian Bateman]

On Wednesday, December 14, 2011 1:43 AM, Anne van Kesteren wrote:
> On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman
>  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

[Jarred Nicholls]

On Wed, Dec 14, 2011 at 11:31 AM, Tab Atkins Jr. wrote:

> On Tue, Dec 13, 2011 at 4:52 PM, Adrian Bateman 
> 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  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

[Adrian Bateman]

On Wednesday, December 14, 2011 2:26 AM, Jonas Sicking wrote:
> On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren 
> wrote:
> > On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman
> >  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

[Glenn Maynard]

On Wed, Dec 14, 2011 at 11:27 AM, Adrian Bateman wrote:

> 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

[Adrian Bateman]

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

[Glenn Maynard]

On Wed, Dec 14, 2011 at 3:00 PM, Adrian Bateman wrote:

> I don't think we need interop for race conditions.


The platform generally tries to eliminate the possibility for race
conditions whenever possible.  It's not always possible, of course, but
adding a new category of races should be thought about carefully,
especially if all it takes to trigger it is "img1.src = img2.src = url".

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.
>

Can you give a specific example?  If there are cases where the spec allows
this to happen, it would help to see whether that's intentional or
something that should be fixed in the spec.

-- 
Glenn Maynard

RE: [FileAPI] createObjectURL isReusable proposal

[James Graham]

On Wed, 14 Dec 2011, Adrian Bateman wrote:


On Wednesday, December 14, 2011 10:46 AM, Glenn Maynard wrote:

We can certainly talk through some of these issues, though the amount of
work we'd need to do doesn't go down. Our proposal is a small change to
the lifetime management of the Blob URL 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

[Glenn Maynard]

On Wed, Dec 14, 2011 at 3:56 PM, Glenn Maynard  wrote:

> 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.
>>
>
> Can you give a specific example?  If there are cases where the spec allows
> this to happen, it would help to see whether that's intentional or
> something that should be fixed in the spec.
>

One possible example: give the URL to XHR, call xhr.send(), then revoke the
URL when send() returns.  The XHR send() method [1] begins the fetch
algorithm asynchronously, so it may or may not succeed, depending on how
far the fetch algorithm has gone before the revoke happens.  (This might be
fixable, if the URL was synchronously resolved to a hard reference to the
underlying blob, before the algorithm goes async and returns.)

This doesn't happen--at least not nearly so easily--for HTMLImageElement
fetches, since it awaits a stable state before beginning the fetch (eg. it
won't begin until you return to the event loop).

[1] http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#the-send-method

-- 
Glenn Maynard

Re: [FileAPI] createObjectURL isReusable proposal

[Ian Hickson]

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

I think it's dangerous 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

[Glenn Maynard]

On Wed, Dec 14, 2011 at 7:40 PM, Ian Hickson  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

[Ian Hickson]

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

[Charles Pritchard]

On 12/14/2011 4:55 PM, Ian Hickson wrote:

On Wed, 14 Dec 2011, Glenn Maynard wrote:

The problem isn't the cost of the URL mapping, it's the cost of keeping
the backing Blob around.  If you drag around Google Maps for a long
time, and it used object URLs to load its tile images, it'd be very bad
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

[Ian Hickson]

On Wed, 14 Dec 2011, Jonas Sicking wrote:
> On Wed, Dec 14, 2011 at 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.
> 
> 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

[Charles Pritchard]

On 12/14/2011 5:10 PM, Ian Hickson wrote:

On Wed, 14 Dec 2011, Jonas Sicking wrote:

On Wed, Dec 14, 2011 at 4:55 PM, Ian 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.

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

[Jonas Sicking]

On Wed, Dec 14, 2011 at 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.

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

[Boris Zbarsky]

On 12/14/11 7:55 PM, Ian Hickson wrote:

Browsers do keep them around for the lifetime of the page, in their HTTP
cache.


Browsers limit the size of the HTTP cache and evict as needed.

-Boris

Re: [FileAPI] createObjectURL isReusable proposal

[Anne van Kesteren]

On Wed, 14 Dec 2011 11:25:38 +0100, Jonas Sicking  wrote:
On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren   
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

[Arun Ranganathan]

Adrian,


- Original Message -
> At TPAC [1,2] I described our proposal for adding an isReusable flag
> to
> createObjectURL. A common pattern we have seen is the need for a blob
> URL
> for a single use (for example, loading into an  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

[Arun Ranganathan]

Glenn points out that the issues raised in this thread weren't totally taken to 
the mat. Once again, sorry for bad nesting in my response: 

> > We can certainly talk through some of these issues, though the
> > amount
> > of
> 
> > work we'd need to do doesn't go down. Our proposal is a small
> > change
> > 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

[Glenn Maynard]

On Fri, Jan 27, 2012 at 11:57 AM, Arun Ranganathan  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

[Darin Fisher]

On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson  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.
>

Re: [FileAPI] createObjectURL isReusable proposal

[Kyle Huey]

On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher  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

[Ian Hickson]

On Sat, 28 Jan 2012, Kyle Huey wrote:
> On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher  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

[Bronislav Klučka]

On 28.1.2012 7:10, Darin Fisher wrote:
On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson > 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

[Glenn Maynard]

On Fri, Jan 27, 2012 at 6:14 PM, Glenn Maynard  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

[Kyle Huey]

Why though?  What stops UAs from accepting the relevant objects for .src
properties?

- Kyle

On Sat, Jan 28, 2012 at 2:47 AM, Ian Hickson  wrote:

> On Sat, 28 Jan 2012, Kyle Huey wrote:
> > On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher 
> 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

[Bronislav Klučka]

It's reference issue

img.src = URL.createObjectUrl(blob)
means, that you cannot GC that blob, because URL is just text 
representation of reference.

img.src = URL.createObjectUrl(blob, true)
means, that you can GC that blob, because once URL is dereferenced, it 
will not be dereferenced again (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 > wrote:


On Sat, 28 Jan 2012, Kyle Huey wrote:
> On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher
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

[Kyle Huey]

2012/1/28 Bronislav Klučka 

> 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

[Bronislav Klučka]

On 30.1.2012 14:40, Kyle Huey wrote:
2012/1/28 Bronislav Klučka >


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

Hi,
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.


B.

Re: [FileAPI] createObjectURL isReusable proposal

[Glenn Maynard]

2012/1/30 Bronislav Klučka 

> 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

[Bronislav Klučka]

On 30.1.2012 15:18, Glenn Maynard wrote:
2012/1/30 Bronislav Klučka >


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

[Glenn Maynard]

2012/1/30 Bronislav Klučka 

> 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("", {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

[Bronislav Klučka]

On 30.1.2012 16:14, Glenn Maynard wrote:
2012/1/30 Bronislav Klučka >


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("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

[Boris Zbarsky]

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

Re: [FileAPI] createObjectURL isReusable proposal

[Bronislav Klučka]

On 30.1.2012 16:56, Boris Zbarsky wrote:

On 1/30/12 10:40 AM, Bronislav Klučka wrote:

img1 = document.getElementById("my-image");
img1.src = URL.createObjectUrl(myBlob);
img2.src = img1.src;
should work like a charm and the URL and blob will be released as soon
as all references will be 0 (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

[Kyle Huey]

2012/1/30 Bronislav Klučka 

> 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

[Boris Zbarsky]

On 1/30/12 11:15 AM, Bronislav Klučka wrote:

In this case you got me... what sense does it make? If there is no
reference to original blob or any other object using that URL, why is it
kept?


Because given a string there is no way to tell whether someone has a
"reference" it.

Consider this:

  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

[Bronislav Klučka]

On 30.1.2012 17:29, Boris Zbarsky wrote:

On 1/30/12 11:15 AM, Bronislav Klučka wrote:

In this case you got me... what sense does it make? If there is no
reference to original blob or any other object using that URL, why is it
kept?


Because given a string there is no way to tell whether 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

Re: [FileAPI] createObjectURL isReusable proposal

[Boris Zbarsky]

On 1/30/12 11:44 AM, Bronislav Klučka wrote:

Both could be solved by Blob.URL, there is no strange string somehow
connected to blob. Blob belongs to URL and URL belongs to blob... who
cares how exactly is the string created (split -> join), it is string
identification, not pointer reference...


That would mean that as soon as you access Blob.URL on a given Blob that
Blob is then leaked for the lifetime of all documents which can touch
that Blob object, right?

Why is that desirable?


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

Re: [FileAPI] createObjectURL isReusable proposal

[Ian Hickson]

On Sat, 28 Jan 2012, Kyle Huey wrote:
>
> Why though?  What stops UAs from accepting the relevant objects for .src 
> properties?

You don't necessarily have an object, e.g. if you're using innerHTML or 
document.write().

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [FileAPI] createObjectURL isReusable proposal

[Bronislav Klučka]

On 30.1.2012 17:51, Boris Zbarsky wrote:

The same blob should have different URLs in different documents, no?

All documents originated from the same application/session/same-origin?


No.  That's the point.  Unless you want the lifetime of the Blob to 
immediately become "while you have any 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

[Arun Ranganathan]

On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson < i...@hixie.ch > wrote: 

> > (From Glenn Maynard)
> 
> > I think it's dangerous to assume that the URL will only be
> > dereferenced
> 
> > once. For example, it would mean that the above image would break
> > if
> > the
> 
> > user toggled images off and back on in a 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-t7lZgzisTuGTXkdzAk4gLU&hl=en&pli=1
 
[2] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0819.html 

Re: [FileAPI] createObjectURL isReusable proposal

[Ian Hickson]

On Thu, 2 Feb 2012, Arun Ranganathan wrote:
> 
> 2. Could we modify things so that img.src = blob is a reality? Mainly, 
> if we modify things for the *most common* use case, that could be useful 
> in mitigating some of our fears. Hixie, is this possible?

Anything's possible, but I think the pain 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

[Charles Pritchard]

On Feb 2, 2012, at 1:40 PM, Ian Hickson  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

[Kyle Huey]

On Thu, Feb 2, 2012 at 4:48 PM, Charles Pritchard  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

[Bronislav Klučka]

On 2.2.2012 21:25, Arun Ranganathan wrote:


Well, I'm a fan of img.src = blob being made a reality, *and* of the 
URL API being solidified.  I'm not 100% sure how we can scope create* 
to an Element in the DOM.  While open to a suggestion that clarifies 
your thoughts on this, I'm worried that 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

[Bronislav Klučka]

On 28.1.2012 8:47, Ian Hickson wrote:

On Sat, 28 Jan 2012, Kyle Huey wrote:

On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher  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; ; 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

[Bronislav Klučka]

On 3.2.2012 7:34, Bronislav Klučka wrote:



On 28.1.2012 8:47, Ian Hickson wrote:

On Sat, 28 Jan 2012, Kyle Huey wrote:
On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher  
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; ; 
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

[Charles Pritchard]

On 2/2/12 10:40 PM, Bronislav Klučka wrote:



On 3.2.2012 7:34, Bronislav Klučka wrote:



On 28.1.2012 8:47, Ian Hickson wrote:

On Sat, 28 Jan 2012, Kyle Huey wrote:
On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher  
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  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

[Bronislav Klučka]

On 3.2.2012 7:51, Charles Pritchard wrote:

On 2/2/12 10:40 PM, Bronislav Klučka wrote:



On 3.2.2012 7:34, Bronislav Klučka wrote:



On 28.1.2012 8:47, Ian Hickson wrote:

On Sat, 28 Jan 2012, Kyle Huey wrote:
On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher  
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  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

[Charles Pritchard]

On 2/2/12 11:08 PM, Bronislav Klučka wrote:

On 3.2.2012 7:51, Charles Pritchard wrote:
I see no reason why an author should expect to stash 100MB of objects 
into createObjectURL, nor any reason why a UA could not manage 100MB 
for the application lifetime; the user can certainly be informed, as 
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 .
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

[Bronislav Klučka]

On 3.2.2012 8:24, Charles Pritchard wrote:

On 2/2/12 11:08 PM, Bronislav Klučka wrote:

On 3.2.2012 7:51, Charles Pritchard wrote:
I see no reason why an author should expect to stash 100MB of 
objects into createObjectURL, nor any reason why a UA could not 
manage 100MB for the application 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 .
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

[Anne van Kesteren]

On Thu, 02 Feb 2012 22:40:12 +0100, Ian Hickson  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

[Bronislav Klučka]

On 3.2.2012 15:13, Anne van Kesteren wrote:

On Thu, 02 Feb 2012 22:40:12 +0100, Ian Hickson  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

[Glenn Maynard]

2012/2/3 Bronislav Klučka 

> 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

[Bronislav Klučka]

On 4.2.2012 5:55, Glenn Maynard wrote:
2012/2/3 Bronislav Klučka >


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

[Glenn Maynard]

If you can't be civil, I'm not going to discuss with you.

2012/2/4 Bronislav Klučka 

>
>
> On 4.2.2012 5:55, Glenn Maynard wrote:
>
>> 2012/2/3 Bronislav Klučka > Bronislav.Klucka@**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

[Jonas Sicking]

On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson  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

[Bronislav Klučka]

On 14.2.2012 5:56, Jonas Sicking wrote:

On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson  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

[Charles Pritchard]

On 2/14/2012 5:35 AM, Bronislav Klučka wrote:



On 14.2.2012 5:56, Jonas Sicking wrote:

On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson  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

[Bronislav Klučka]

On 14.2.2012 14:39, Charles Pritchard wrote:

On 2/14/2012 5:35 AM, Bronislav Klučka wrote:



On 14.2.2012 5:56, Jonas Sicking wrote:

On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson  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

[Glenn Maynard]

2012/2/14 Bronislav Klučka 

> 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

[Bronislav Klučka]

On 14.2.2012 15:20, Glenn Maynard wrote:
2012/2/14 Bronislav Klučka >


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

[Bronislav Klučka]

On 14.2.2012 5:56, Jonas Sicking wrote:

On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson  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

[Arun Ranganathan]

Bronislav,

 
> I could also go with reverse approach, with createObjectURL being
> oneTimeOnly by default
> createObjectURL(Blob aBlob, boolean? isPermanent)
> instead of current
> createObjectURL(Blob aBlob, boolean? isOneTime)
> the fact, that user would have to explicitly specify, that such URL
> is
> 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

[Bronislav Klučka]

On 24.2.2012 20:12, Arun Ranganathan wrote:

Bronislav,



I could also go with reverse approach, with createObjectURL being
oneTimeOnly by default
createObjectURL(Blob aBlob, boolean? isPermanent)
instead of current
createObjectURL(Blob aBlob, boolean? isOneTime)
the fact, that user would have 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

[Arun Ranganathan]

> On 24.2.2012 20:12, Arun Ranganathan wrote:
> > Bronislav,
> >
> >
> >> I could also go with reverse approach, with createObjectURL being
> >> oneTimeOnly by default
> >> createObjectURL(Blob aBlob, boolean? isPermanent)
> >> instead of current
> >> createObjectURL(Blob aBlob, boolean? isOneTime)
> >> the fact, that 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

[Bronislav Klučka]

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.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*
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

[Feras Moussa]

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

[Glenn Maynard]

On Wed, Feb 29, 2012 at 9:38 PM, Feras Moussa  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

[Bronislav Klučka]

On 1.3.2012 4:38, Feras Moussa wrote:

We think the new property bag (objectURLOptions) semantics in the latest
editors draft are very reasonable. We have an implementation of this and
from our experience have found it very widely used internally with app
developers - many leverage it as a way 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

[Robert O'Callahan]

On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking  wrote:

> On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson  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

[Bronislav Klučka]

On 27.3.2012 11:43, Robert O'Callahan wrote:

On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking  wrote:

On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson 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

Fwd: Re: [FileAPI] createObjectURL isReusable proposal

[Bronislav Klučka]

 Original Message 
Subject:Re: [FileAPI] createObjectURL isReusable proposal
Date:   Mon, 30 Jan 2012 17:51:55 +0100
From:   Bronislav Klučka 
To: Boris Zbarsky 



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