subject:"createBlobURL"

On Mon, Oct 25, 2010 at 7:48 PM, Jonas Sicking  wrote:
> On Mon, Oct 25, 2010 at 6:10 PM, Tab Atkins Jr.  wrote:
>> On Mon, Oct 25, 2010 at 5:59 PM, Jonas Sicking  wrote:
>>> However it still leaves my original statement unanswered:
>>>
>>> "Like I said, I think creating an OM that covers all the cases here
>>> would create something very complex. I'd love to see a useful proposal
>>> for "
>>
>> I outlined how it would work above, I thought.  Any property that can
>> take a  should, in the Values API, be able to take a url object
>> like we're describing here.  Any function that can take a  as an
>> argument should do the same.  The exact interface for exposing
>> function arguments hasn't been nailed down yet, but once you can do
>> so, using it should be the same as using an ordinary property which
>> just takes a .
>
> The question is, how do you use a DOMURL together with all the other
> features of . Using the createObjectURL proposal I can do:
>
> elem.style.backgroundImage =
> "image('" + createObjectURL(file1) + "' snap 150dpi)," +
> "image('" + createObjectURL(file2) + "' 150dpi, radial-gradient(...))";
>
> How would I do the equivalent if createObjectURL isn't available?

*Definitely* not with the current CSSOM.  String concatenation is
disgusting API design in the first place.

Anne hasn't proposed a way to handle functions and their arguments yet
in the Values API, so I can only speculate.  Particularly, initially
setting a new function is a bit of a mystery.  I could think of a few
possible ways to do it, though.

1)
elem.style.values.backgroundImage.function = new
CSSFunctionImage([file1, 'snap', {dpi:150}], [file2, {dpi:150}], new
CSSFunctionRadialGradient(...));

2)
elem.style.backgroundImage = "image(url(404) snap 150dpi, url(404)
150dpi, radial-gradient(...))";
elem.style.values.backgroundImage.function.a[0].url = file1;
elem.style.values.backgroundImage.function.a[1].url = file2;

Both of these are off the top of my head, so don't read too much into
them.  The point is just to illustrate that the issue is solveable.

~TJ

Re: createBlobURL

On Mon, Oct 25, 2010 at 6:10 PM, Tab Atkins Jr.  wrote:
> On Mon, Oct 25, 2010 at 5:59 PM, Jonas Sicking  wrote:
>> On Mon, Oct 25, 2010 at 5:56 PM, Tab Atkins Jr.  wrote:
>>> On Mon, Oct 25, 2010 at 5:51 PM, Jonas Sicking  wrote:
 On Mon, Oct 25, 2010 at 5:04 PM, Tab Atkins Jr.  
 wrote:
> On Mon, Oct 25, 2010 at 4:48 PM, Jonas Sicking  wrote:
>> Like I said, I think creating an OM that covers all the cases here
>> would create something very complex. I'd love to see a useful proposal
>> for .
>
> It doesn't seem overly difficult.  Using the proposed Values API,
> you'd do something like "elem.style.values.backgroundImage.url =
> [DOMURL goes here]".

 That doesn't cover nearly all the ways you can use URLs as defined in
 http://dev.w3.org/csswg/css3-images/ which support multiple levels of
 fallback images, with snapping and resolution as well as gradients and
 fallback colors. And with used in a property like backgroundImage, you
 can have several combined instances of those. Consider:

 style="background-image: image(sun.svg, 'sun.png' snap 150dpi),
 image(wavy.svg, 'wavy.png' 150dpi, 'wavy.gif', radial-gradient(...))"
>>>
>>> This would be part of the  interface, and would be accepted
>>> anywhere a  is currently accepted.  Exposing the correct
>>> interface of function arguments would be a job for the function
>>> interface in the Values API, and is designed to be orthogonal.
>>
>> Note that the syntax for images is significantly different from the
>> syntax for urls. So I suspect you mean  rather than 
>> above.
>
> No, I meant , which happens to be a type of  as well.  I
> don't know what it would mean for me to mean , as that covers
> much more than what you can produce with a blob.
>
>
>> However it still leaves my original statement unanswered:
>>
>> "Like I said, I think creating an OM that covers all the cases here
>> would create something very complex. I'd love to see a useful proposal
>> for "
>
> I outlined how it would work above, I thought.  Any property that can
> take a  should, in the Values API, be able to take a url object
> like we're describing here.  Any function that can take a  as an
> argument should do the same.  The exact interface for exposing
> function arguments hasn't been nailed down yet, but once you can do
> so, using it should be the same as using an ordinary property which
> just takes a .

The question is, how do you use a DOMURL together with all the other
features of . Using the createObjectURL proposal I can do:

elem.style.backgroundImage =
"image('" + createObjectURL(file1) + "' snap 150dpi)," +
"image('" + createObjectURL(file2) + "' 150dpi, radial-gradient(...))";

How would I do the equivalent if createObjectURL isn't available?

/ Jonas

Re: createBlobURL

On Mon, Oct 25, 2010 at 5:59 PM, Jonas Sicking  wrote:
> On Mon, Oct 25, 2010 at 5:56 PM, Tab Atkins Jr.  wrote:
>> On Mon, Oct 25, 2010 at 5:51 PM, Jonas Sicking  wrote:
>>> On Mon, Oct 25, 2010 at 5:04 PM, Tab Atkins Jr.  
>>> wrote:
 On Mon, Oct 25, 2010 at 4:48 PM, Jonas Sicking  wrote:
> Like I said, I think creating an OM that covers all the cases here
> would create something very complex. I'd love to see a useful proposal
> for .

 It doesn't seem overly difficult.  Using the proposed Values API,
 you'd do something like "elem.style.values.backgroundImage.url =
 [DOMURL goes here]".
>>>
>>> That doesn't cover nearly all the ways you can use URLs as defined in
>>> http://dev.w3.org/csswg/css3-images/ which support multiple levels of
>>> fallback images, with snapping and resolution as well as gradients and
>>> fallback colors. And with used in a property like backgroundImage, you
>>> can have several combined instances of those. Consider:
>>>
>>> style="background-image: image(sun.svg, 'sun.png' snap 150dpi),
>>> image(wavy.svg, 'wavy.png' 150dpi, 'wavy.gif', radial-gradient(...))"
>>
>> This would be part of the  interface, and would be accepted
>> anywhere a  is currently accepted.  Exposing the correct
>> interface of function arguments would be a job for the function
>> interface in the Values API, and is designed to be orthogonal.
>
> Note that the syntax for images is significantly different from the
> syntax for urls. So I suspect you mean  rather than 
> above.

No, I meant , which happens to be a type of  as well.  I
don't know what it would mean for me to mean , as that covers
much more than what you can produce with a blob.


> However it still leaves my original statement unanswered:
>
> "Like I said, I think creating an OM that covers all the cases here
> would create something very complex. I'd love to see a useful proposal
> for "

I outlined how it would work above, I thought.  Any property that can
take a  should, in the Values API, be able to take a url object
like we're describing here.  Any function that can take a  as an
argument should do the same.  The exact interface for exposing
function arguments hasn't been nailed down yet, but once you can do
so, using it should be the same as using an ordinary property which
just takes a .

~TJ

Re: createBlobURL

On Mon, Oct 25, 2010 at 5:56 PM, Tab Atkins Jr.  wrote:
> On Mon, Oct 25, 2010 at 5:51 PM, Jonas Sicking  wrote:
>> On Mon, Oct 25, 2010 at 5:04 PM, Tab Atkins Jr.  wrote:
>>> On Mon, Oct 25, 2010 at 4:48 PM, Jonas Sicking  wrote:
 Like I said, I think creating an OM that covers all the cases here
 would create something very complex. I'd love to see a useful proposal
 for .
>>>
>>> It doesn't seem overly difficult.  Using the proposed Values API,
>>> you'd do something like "elem.style.values.backgroundImage.url =
>>> [DOMURL goes here]".
>>
>> That doesn't cover nearly all the ways you can use URLs as defined in
>> http://dev.w3.org/csswg/css3-images/ which support multiple levels of
>> fallback images, with snapping and resolution as well as gradients and
>> fallback colors. And with used in a property like backgroundImage, you
>> can have several combined instances of those. Consider:
>>
>> style="background-image: image(sun.svg, 'sun.png' snap 150dpi),
>> image(wavy.svg, 'wavy.png' 150dpi, 'wavy.gif', radial-gradient(...))"
>
> This would be part of the  interface, and would be accepted
> anywhere a  is currently accepted.  Exposing the correct
> interface of function arguments would be a job for the function
> interface in the Values API, and is designed to be orthogonal.

Note that the syntax for images is significantly different from the
syntax for urls. So I suspect you mean  rather than 
above.

However it still leaves my original statement unanswered:

"Like I said, I think creating an OM that covers all the cases here
would create something very complex. I'd love to see a useful proposal
for "

/ Jonas

Re: createBlobURL

On Mon, Oct 25, 2010 at 5:51 PM, Jonas Sicking  wrote:
> On Mon, Oct 25, 2010 at 5:04 PM, Tab Atkins Jr.  wrote:
>> On Mon, Oct 25, 2010 at 4:48 PM, Jonas Sicking  wrote:
>>> Like I said, I think creating an OM that covers all the cases here
>>> would create something very complex. I'd love to see a useful proposal
>>> for .
>>
>> It doesn't seem overly difficult.  Using the proposed Values API,
>> you'd do something like "elem.style.values.backgroundImage.url =
>> [DOMURL goes here]".
>
> That doesn't cover nearly all the ways you can use URLs as defined in
> http://dev.w3.org/csswg/css3-images/ which support multiple levels of
> fallback images, with snapping and resolution as well as gradients and
> fallback colors. And with used in a property like backgroundImage, you
> can have several combined instances of those. Consider:
>
> style="background-image: image(sun.svg, 'sun.png' snap 150dpi),
> image(wavy.svg, 'wavy.png' 150dpi, 'wavy.gif', radial-gradient(...))"

This would be part of the  interface, and would be accepted
anywhere a  is currently accepted.  Exposing the correct
interface of function arguments would be a job for the function
interface in the Values API, and is designed to be orthogonal.

~TJ

Re: createBlobURL

On Mon, Oct 25, 2010 at 5:04 PM, Tab Atkins Jr.  wrote:
> On Mon, Oct 25, 2010 at 4:48 PM, Jonas Sicking  wrote:
>> Like I said, I think creating an OM that covers all the cases here
>> would create something very complex. I'd love to see a useful proposal
>> for .
>
> It doesn't seem overly difficult.  Using the proposed Values API,
> you'd do something like "elem.style.values.backgroundImage.url =
> [DOMURL goes here]".

That doesn't cover nearly all the ways you can use URLs as defined in
http://dev.w3.org/csswg/css3-images/ which support multiple levels of
fallback images, with snapping and resolution as well as gradients and
fallback colors. And with used in a property like backgroundImage, you
can have several combined instances of those. Consider:

style="background-image: image(sun.svg, 'sun.png' snap 150dpi),
image(wavy.svg, 'wavy.png' 150dpi, 'wavy.gif', radial-gradient(...))"

/ Jonas

Re: createBlobURL

On Mon, Oct 25, 2010 at 4:48 PM, Jonas Sicking  wrote:
> Like I said, I think creating an OM that covers all the cases here
> would create something very complex. I'd love to see a useful proposal
> for .

It doesn't seem overly difficult.  Using the proposed Values API,
you'd do something like "elem.style.values.backgroundImage.url =
[DOMURL goes here]".

Then you'd just have to define the serialization of this to cssText,
which would probably just involve an opaque URL like "about:url" or
something similar.  It wouldn't roundtrip through a string, but that's
probably an acceptable penalty.

~TJ

Re: createBlobURL

On Mon, Oct 25, 2010 at 6:09 AM, Anne van Kesteren  wrote:
> On Thu, 21 Oct 2010 19:47:08 +0200, Jonas Sicking  wrote:
>>
>> On Thu, Oct 21, 2010 at 3:50 AM, Anne van Kesteren 
>> wrote:
>>>
>>> If that is the only real solution I suggest we do that. We can create
>>> some kind of DOMURL type which is either a DOMString or a URL/Blob/something
>>> and change the relevant APIs.
>>
>> This means that you can't use File objects together with things like
>> .innerHTML (neither the getter nor setter) or things like
>> CSSStyleDeclaration.background. Actually, it doesn't even work with
>> CSSStyleDeclaration.backgroundImage since it can be a list of URLs.
>> And with the CSS Image Values spec [1] it can be something much more
>> complex.
>
> It does not work with backgroundImage either way, as the syntax is not just
> a URL represented as a string, but a special kind of CSS URL string.

Indeed. I suspect background images might be a pretty common use case.
Though maybe people can use normal s most of the time.

>> If we don't want to use blob-URLs at all, we have to track down every
>> single DOM property which deals with URLs and:
>>
>> A. Make sure that it doesn't use strings where URLs is part of the
>> string (like .innerHTML or CSSStyleDeclaration.background). If it
>> does, create a new object model that breaks down the string into
>> components where the URL is a separate component.
>> B. Make it take a DOMURL instead of a DOMString
>
> Right.
>
>> While I agree that memory management is a horrible thing to thrust
>> upon developers, I really don't see an option here. It would
>> complicate matters hugely in cases like
>> CSSStyleDeclaration.backgroundImage. Can you even make a proposal for
>> what the object model would look like which would work for [1]?
>
> The CSS WG is working on an a better object model for CSS values that would
> cover that case.

Like I said, I think creating an OM that covers all the cases here
would create something very complex. I'd love to see a useful proposal
for [1].

>> And as stated before, I think a hugely mitigating factor here is that
>> the amount of memory leaked is very small.
>
> But not small enough apparently to simply not bother with a way of cleaning
> it up.

Yup. I don't think any leak > 0 is small enough not to bother cleaning up.

>> What I think we should do is to fine the places where people are most
>> likely to use blob-urls and in those cases change DOMString to DOMURL.
>> Such as HTMLImageElement.src like Darin proposes. But for the
>> remaining places keep createObjectURL/revokeObjectURL. I would imagine
>> that by just fixing a handful of properties we can cover 95% of the
>> use cases and make those not require the author to do memory
>> management.
>
> 95% seems way higher than our typical 80/20 goal. Why do we want to even
> bother with covering the other cases? We could start out with just DOMURL
> and if there is a real pressing need for more only then introduce those
> methods instead of doing everything right away.

I think this would be a significant limitation. Maybe not in the
number of sites using it, but in the number of things that you could
build. If this really is what everyone wants to do though, I guess I'd
be fine with leaving createObjectURL out of the spec for now and just
leave it vendor prefixed in Firefox. Though so far you are the only
one that has suggested this. Possibly also Maciej who a long time ago
raised concerns about the resource-managament-through-string-value
problem too.

>> [1] http://dev.w3.org/csswg/css3-images/

/ Jonas

Re: createBlobURL

2010-10-25 Thread Anne van Kesteren


On Thu, 21 Oct 2010 19:47:08 +0200, Jonas Sicking  wrote:
On Thu, Oct 21, 2010 at 3:50 AM, Anne van Kesteren   
wrote:
If that is the only real solution I suggest we do that. We can create  
some kind of DOMURL type which is either a DOMString or a  
URL/Blob/something and change the relevant APIs.


This means that you can't use File objects together with things like
.innerHTML (neither the getter nor setter) or things like
CSSStyleDeclaration.background. Actually, it doesn't even work with
CSSStyleDeclaration.backgroundImage since it can be a list of URLs.
And with the CSS Image Values spec [1] it can be something much more
complex.


It does not work with backgroundImage either way, as the syntax is not  
just a URL represented as a string, but a special kind of CSS URL string.




If we don't want to use blob-URLs at all, we have to track down every
single DOM property which deals with URLs and:

A. Make sure that it doesn't use strings where URLs is part of the
string (like .innerHTML or CSSStyleDeclaration.background). If it
does, create a new object model that breaks down the string into
components where the URL is a separate component.
B. Make it take a DOMURL instead of a DOMString


Right.



While I agree that memory management is a horrible thing to thrust
upon developers, I really don't see an option here. It would
complicate matters hugely in cases like
CSSStyleDeclaration.backgroundImage. Can you even make a proposal for
what the object model would look like which would work for [1]?


The CSS WG is working on an a better object model for CSS values that  
would cover that case.




And as stated before, I think a hugely mitigating factor here is that
the amount of memory leaked is very small.


But not small enough apparently to simply not bother with a way of  
cleaning it up.




What I think we should do is to fine the places where people are most
likely to use blob-urls and in those cases change DOMString to DOMURL.
Such as HTMLImageElement.src like Darin proposes. But for the
remaining places keep createObjectURL/revokeObjectURL. I would imagine
that by just fixing a handful of properties we can cover 95% of the
use cases and make those not require the author to do memory
management.


95% seems way higher than our typical 80/20 goal. Why do we want to even  
bother with covering the other cases? We could start out with just DOMURL  
and if there is a real pressing need for more only then introduce those  
methods instead of doing everything right away.




[1] http://dev.w3.org/csswg/css3-images/




--
Anne van Kesteren
http://annevankesteren.nl/

Re: createBlobURL

2010-10-21 Thread Jonas Sicking

On Thu, Oct 21, 2010 at 3:50 AM, Anne van Kesteren  wrote:
> On Wed, 20 Oct 2010 01:57:30 +0200, Jonas Sicking  wrote:
>>
>> The only real solution here is to abandon the use of URLs-strings
>> ("blob:...") and instead use some type of object which represents a
>> reference to the blob/stream/whatever. Then make img.src, iframe.src,
>> CSSStyleDeclaration.backgroundImage etc accept this new type in
>> addition to a string.
>
> If that is the only real solution I suggest we do that. We can create some
> kind of DOMURL type which is either a DOMString or a URL/Blob/something and
> change the relevant APIs.

This means that you can't use File objects together with things like
.innerHTML (neither the getter nor setter) or things like
CSSStyleDeclaration.background. Actually, it doesn't even work with
CSSStyleDeclaration.backgroundImage since it can be a list of URLs.
And with the CSS Image Values spec [1] it can be something much more
complex.

If we don't want to use blob-URLs at all, we have to track down every
single DOM property which deals with URLs and:

A. Make sure that it doesn't use strings where URLs is part of the
string (like .innerHTML or CSSStyleDeclaration.background). If it
does, create a new object model that breaks down the string into
components where the URL is a separate component.
B. Make it take a DOMURL instead of a DOMString

While I agree that memory management is a horrible thing to thrust
upon developers, I really don't see an option here. It would
complicate matters hugely in cases like
CSSStyleDeclaration.backgroundImage. Can you even make a proposal for
what the object model would look like which would work for [1]?

And as stated before, I think a hugely mitigating factor here is that
the amount of memory leaked is very small.

What I think we should do is to fine the places where people are most
likely to use blob-urls and in those cases change DOMString to DOMURL.
Such as HTMLImageElement.src like Darin proposes. But for the
remaining places keep createObjectURL/revokeObjectURL. I would imagine
that by just fixing a handful of properties we can cover 95% of the
use cases and make those not require the author to do memory
management.

[1] http://dev.w3.org/csswg/css3-images/

/ Jonas

Re: createBlobURL

2010-10-21 Thread Arun Ranganathan


 On 10/21/10 6:50 AM, Anne van Kesteren wrote:
On Wed, 20 Oct 2010 01:57:30 +0200, Jonas Sicking  
wrote:

The only real solution here is to abandon the use of URLs-strings
("blob:...") and instead use some type of object which represents a
reference to the blob/stream/whatever. Then make img.src, iframe.src,
CSSStyleDeclaration.backgroundImage etc accept this new type in
addition to a string.


If that is the only real solution I suggest we do that. We can create 
some kind of DOMURL type which is either a DOMString or a 
URL/Blob/something and change the relevant APIs.





This is an attractive direction that could help with the revocation 
problem (and maybe even spare some IANA work with 
registering/formalizing blob: if in the end we abandon URL strings, but 
I'd rather not skip ahead).  I'm in favor of vendor-prefixing the 
create*URL revoke*URL methods, but I leave that to implementers.

Re: createBlobURL

2010-10-21 Thread Anne van Kesteren

On Tue, 19 Oct 2010 18:01:52 +0200, Arun Ranganathan   
wrote:
Fair point.  It is conceivable that the URL API can evolve to include  
creation of Blob and Stream URLs using the blob: scheme in constructors,  
including revocation mechanism for these (yes, programmer/user assisted  
revocation is necessary).  If and when that happens, we can deprecate  
these other methods (createObjectURL and revokeObjectURL).


Deprecating does not work. The clutter will remain on the window object  
and we will likely have to support them for eternity. We should use some  
caution here.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: createBlobURL

2010-10-21 Thread Anne van Kesteren


On Wed, 20 Oct 2010 01:57:30 +0200, Jonas Sicking  wrote:

The only real solution here is to abandon the use of URLs-strings
("blob:...") and instead use some type of object which represents a
reference to the blob/stream/whatever. Then make img.src, iframe.src,
CSSStyleDeclaration.backgroundImage etc accept this new type in
addition to a string.


If that is the only real solution I suggest we do that. We can create some  
kind of DOMURL type which is either a DOMString or a URL/Blob/something  
and change the relevant APIs.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: createBlobURL

2010-10-20 Thread Darin Fisher

On Tue, Oct 19, 2010 at 4:57 PM, Jonas Sicking  wrote:

> On Tue, Oct 19, 2010 at 1:24 AM, Anne van Kesteren 
> wrote:
> > On Mon, 18 Oct 2010 20:15:53 +0200, Jonas Sicking 
> wrote:
> >>
> >> Without revoking the UA has to keep around the URL-string -> resource
> >> mapping for the lifetime of the page. Which in the world of web apps
> >> can be a very long time. Even worse, in the case of dynamically
> >> created blobs (blobbuilder, canvas.toFile/toBlob/getAsFile whatever
> >> we'll call it), the resource has to stay around at least on the users
> >> file system for the lifetime of the page.
> >
> > So we are moving the responsibility to do things right to authors? Oh
> joy.
> > Though I suppose it might just work for the most complex of applications,
> > where they measure things such as memory usage, etc.
>
> Suggestions welcome. The base problem here is that we are doing
> resource management using a string-value rather than using a
> object-reference. It is provably impossible for the implementation to
> know if a given url is going to get used in the future (since it
> requires solving the halting problem).
>
> The only real solution here is to abandon the use of URLs-strings
> ("blob:...") and instead use some type of object which represents a
> reference to the blob/stream/whatever. Then make img.src, iframe.src,
> CSSStyleDeclaration.backgroundImage etc accept this new type in
> addition to a string.
>

I had a similar thought the other day.  However, why not just support
assigning a
Blob/Stream directly to img.src, iframe.src, etc.?  Why does there need to
be any
other representation of the data source?

(I'm not suggesting we abandon blob: URLs completely.)

-Darin



>
> I think the main mitigating factor here is that as far as memory usage
> goes, the only thing "leaked" is an entry in a hash-table, so in the
> order of 50 bytes for each generated url.
>
> / Jonas
>

Re: createBlobURL

2010-10-19 Thread Jonas Sicking

On Tue, Oct 19, 2010 at 1:20 AM, Anne van Kesteren  wrote:
> On Tue, 19 Oct 2010 02:30:39 +0200, Jonas Sicking  wrote:
>>
>> I agree. Another thing that is nice about the window.*BlobURL() API is
>> that it makes it clear which origin the created url will have. I.e.
>> the origin of the window which it's called on.
>>
>> We could maintain that even if we used a URL constructor by saying
>> that it's tied to the window whose .URL property was used as
>> constructor, but it makes it a much more indirect connection.
>
> It is not any less direct than how it works for new XMLHttpRequest, new
> Worker, new EventSource, and any other number of constructors where URLs are
> somehow involved in the objects they create. I do not really see why new URL
> would be special here.

I would say there is one more level of indirection, since people won't
use the URL object, but rather the return value from its .href
property.

Additionally, I don't see what the value is of getting a URL object
for a blob: url is? URLs are mostly useful when resolving relative
references, but that never works for blob: urls. So we'd force people
to always create a URL object and immediately throw it away.

Another downside is that we lose the symmetry of
createObjectURL/revokeObjectURL. It's still unclear where you are
proposing the revoke function would be, but I can't think of any
syntax which would have symmetry with a constructor.

/ Jonas

Re: createBlobURL

2010-10-19 Thread Jonas Sicking

On Tue, Oct 19, 2010 at 1:24 AM, Anne van Kesteren  wrote:
> On Mon, 18 Oct 2010 20:15:53 +0200, Jonas Sicking  wrote:
>>
>> Without revoking the UA has to keep around the URL-string -> resource
>> mapping for the lifetime of the page. Which in the world of web apps
>> can be a very long time. Even worse, in the case of dynamically
>> created blobs (blobbuilder, canvas.toFile/toBlob/getAsFile whatever
>> we'll call it), the resource has to stay around at least on the users
>> file system for the lifetime of the page.
>
> So we are moving the responsibility to do things right to authors? Oh joy.
> Though I suppose it might just work for the most complex of applications,
> where they measure things such as memory usage, etc.

Suggestions welcome. The base problem here is that we are doing
resource management using a string-value rather than using a
object-reference. It is provably impossible for the implementation to
know if a given url is going to get used in the future (since it
requires solving the halting problem).

The only real solution here is to abandon the use of URLs-strings
("blob:...") and instead use some type of object which represents a
reference to the blob/stream/whatever. Then make img.src, iframe.src,
CSSStyleDeclaration.backgroundImage etc accept this new type in
addition to a string.

I think the main mitigating factor here is that as far as memory usage
goes, the only thing "leaked" is an entry in a hash-table, so in the
order of 50 bytes for each generated url.

/ Jonas

Re: createBlobURL

2010-10-19 Thread Arun Ranganathan


 On 10/19/10 4:20 AM, Anne van Kesteren wrote:
On Tue, 19 Oct 2010 02:30:39 +0200, Jonas Sicking  
wrote:

I agree. Another thing that is nice about the window.*BlobURL() API is
that it makes it clear which origin the created url will have. I.e.
the origin of the window which it's called on.

We could maintain that even if we used a URL constructor by saying
that it's tied to the window whose .URL property was used as
constructor, but it makes it a much more indirect connection.


It is not any less direct than how it works for new XMLHttpRequest, 
new Worker, new EventSource, and any other number of constructors 
where URLs are somehow involved in the objects they create. I do not 
really see why new URL would be special here.


Fair point.  It is conceivable that the URL API can evolve to include 
creation of Blob and Stream URLs using the blob: scheme in constructors, 
including revocation mechanism for these (yes, programmer/user assisted 
revocation is necessary).  If and when that happens, we can deprecate 
these other methods (createObjectURL and revokeObjectURL).


I look forward to seeing the URL API mature into a real specification, 
and seeing some prototypes.


-- A*

Re: createBlobURL

2010-10-19 Thread Anne van Kesteren


On Mon, 18 Oct 2010 20:15:53 +0200, Jonas Sicking  wrote:

Without revoking the UA has to keep around the URL-string -> resource
mapping for the lifetime of the page. Which in the world of web apps
can be a very long time. Even worse, in the case of dynamically
created blobs (blobbuilder, canvas.toFile/toBlob/getAsFile whatever
we'll call it), the resource has to stay around at least on the users
file system for the lifetime of the page.


So we are moving the responsibility to do things right to authors? Oh joy.  
Though I suppose it might just work for the most complex of applications,  
where they measure things such as memory usage, etc.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: createBlobURL

2010-10-19 Thread Anne van Kesteren


On Tue, 19 Oct 2010 02:30:39 +0200, Jonas Sicking  wrote:

I agree. Another thing that is nice about the window.*BlobURL() API is
that it makes it clear which origin the created url will have. I.e.
the origin of the window which it's called on.

We could maintain that even if we used a URL constructor by saying
that it's tied to the window whose .URL property was used as
constructor, but it makes it a much more indirect connection.


It is not any less direct than how it works for new XMLHttpRequest, new  
Worker, new EventSource, and any other number of constructors where URLs  
are somehow involved in the objects they create. I do not really see why  
new URL would be special here.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: createBlobURL

2010-10-18 Thread Arun Ranganathan


 On 10/18/10 8:30 PM, Jonas Sicking wrote:

On Mon, Oct 18, 2010 at 5:17 PM, Michael Nordman  wrote:

Chrome currently has this as...
 DOMString createBlobURL(in Blob blob);
 void revokeBlobURL(in DOMString blobURL);
... no prefix... on both Window and WorkerContext.
An important aspect of placing these interfaces on the Window and
WorkerContext was to scope the lifetime of the manufactured url to the
respective window or worker object.  I thought adam's url api was all about
parsing and building valid urls, so i'm not sure these methods are such a
good fit for that interface.

I agree. Another thing that is nice about the window.*BlobURL() API is
that it makes it clear which origin the created url will have. I.e.
the origin of the window which it's called on.


I agree too, and upon reflection, I'm sorry I let myself get distracted 
by the URL API (but thanks anyway Anne for making me re-read it and 
contemplate its future ;-)).

Renaming to createObjectURL/revokeObjectURL seems like the most
straightforward way to generify the existing methods.

I talked with Arun about this, and one argument was that we can keep
the createBlobURL name since the returned url always uses the scheme
'blob'. However I have to say that I really like the
createObjectURL/revokeObjectURL names, and it might create less
confusion.

So createObjectURL/revokeObjectURL has my vote.



Well, that's two implementers who have working prototypes of 
createBlobURL and revokeBlobURL, and since you and Michael are in favor 
of the name change on behalf of the implementers, that's fine by me to 
rename it :).  I'll make this change.  Moreover, no need to hold up the 
CfC on this account, since these changes are easy to make.


Future proponents of the nascent Stream API [1] can simply create 
another [Supplemental] interface (or further extend the existing one) to 
allow createObjectURL to take a Stream object and return a blob: URL.  
So that future proofs us elegantly enough.


-- A*
[1] http://dev.w3.org/html5/html-device/#stream-api

Re: createBlobURL

On Mon, Oct 18, 2010 at 5:17 PM, Michael Nordman  wrote:
> Chrome currently has this as...
>         DOMString createBlobURL(in Blob blob);
>         void revokeBlobURL(in DOMString blobURL);
> ... no prefix... on both Window and WorkerContext.
> An important aspect of placing these interfaces on the Window and
> WorkerContext was to scope the lifetime of the manufactured url to the
> respective window or worker object.  I thought adam's url api was all about
> parsing and building valid urls, so i'm not sure these methods are such a
> good fit for that interface.

I agree. Another thing that is nice about the window.*BlobURL() API is
that it makes it clear which origin the created url will have. I.e.
the origin of the window which it's called on.

We could maintain that even if we used a URL constructor by saying
that it's tied to the window whose .URL property was used as
constructor, but it makes it a much more indirect connection.

> Renaming to createObjectURL/revokeObjectURL seems like the most
> straightforward way to generify the existing methods.

I talked with Arun about this, and one argument was that we can keep
the createBlobURL name since the returned url always uses the scheme
'blob'. However I have to say that I really like the
createObjectURL/revokeObjectURL names, and it might create less
confusion.

So createObjectURL/revokeObjectURL has my vote.

/ Jonas

> On Mon, Oct 18, 2010 at 11:50 AM, Arun Ranganathan  wrote:
>>
>>  On 10/18/10 12:16 PM, Anne van Kesteren wrote:
>>>
>>> On Mon, 18 Oct 2010 18:09:24 +0200, Jonas Sicking 
>>> wrote:
>>>>
>>>> I would be ok with moz prefixing, though it would be nice to try to
>>>> find a solution pretty quickly if all this is is a discussion about
>>>> finding an appropriate name for this function.
>>>
>>> Well, if people agree with me that the appropriate place would be the URL
>>> object -- assuming for now we are going to get that -- it would be more
>>> involved than just renaming.
>>
>> Moving these features to the URL object is more complex, but may be
>> desirable.  I'm not sure I can shoe horn that big an adjustment in time for
>> the CfC (not least of all because there isn't a draft of the URL API I can
>> refer to.  I suppose I could specify the object that Adam has started with
>> in the File API draft, though).  Maybe more discussion is warranted at a
>> venue like the TPAC.
>>
>> However, the revocation capability is pretty essential.  So this is
>> something we'd have to add to the URL API.  And, the URL API has to be
>> robust enough for both Stream and Blob use cases.
>>
>> Since Anne's suggestion is an important but late-breaking one, I'd propose
>> tabling a CfC till the editor's draft accurately reflects consensus on what
>> to do with URL generation and revocation for Blobs.  Maybe one thing we can
>> do with existing implementation trains is:
>>
>> 1. Use vendor prefixing for create* and revoke* according to some rules
>> [1] (since underscores are rarely used in DOM APIs, we'd have
>> window.moz_createBlobURL() or chrome_createBlobURL( ) ), but I'd really like
>> to hear from the Chromium folks.  Darin?  Others?
>>
>> 2. Adding revoke* to Adam's URL *or* create more versatile APIs that are
>> better named within window* that account for Stream *and* Blob.
>>
>> A benefit *and* a drawback of reusing the URL object is that this would
>> make Blob URLs and HTTP URLs within the same object.  It makes sense to
>> revoke a Blob URL, but much less sense to revoke another URL.  The schemes
>> are different, but they *do* behave pretty much similarly.
>>
>> I'd like a bit more implementer feedback, especially since doing 2. would
>> be a pretty late breaking change.  I'm in favor of the best solution, but
>> hate late breaking changes.  Chrome folks?
>>
>> -- A*
>> [1]
>> https://wiki.mozilla.org/Tantek-Mozilla-projects#DOM_API_vendor_prefixing
>>
>
>

Re: createBlobURL

2010-10-18 Thread Michael Nordman

Chrome currently has this as...
DOMString createBlobURL(in Blob blob);
void revokeBlobURL(in DOMString blobURL);
... no prefix... on both Window and WorkerContext.

An important aspect of placing these interfaces on the Window and
WorkerContext was to scope the lifetime of the manufactured url to the
respective window or worker object.  I thought adam's url api was all about
parsing and building valid urls, so i'm not sure these methods are such a
good fit for that interface.

Renaming to createObjectURL/revokeObjectURL seems like the most
straightforward way to generify the existing methods.

On Mon, Oct 18, 2010 at 11:50 AM, Arun Ranganathan  wrote:

>  On 10/18/10 12:16 PM, Anne van Kesteren wrote:
>
>> On Mon, 18 Oct 2010 18:09:24 +0200, Jonas Sicking 
>> wrote:
>>
>>> I would be ok with moz prefixing, though it would be nice to try to
>>> find a solution pretty quickly if all this is is a discussion about
>>> finding an appropriate name for this function.
>>>
>>
>> Well, if people agree with me that the appropriate place would be the URL
>> object -- assuming for now we are going to get that -- it would be more
>> involved than just renaming.
>>
>
> Moving these features to the URL object is more complex, but may be
> desirable.  I'm not sure I can shoe horn that big an adjustment in time for
> the CfC (not least of all because there isn't a draft of the URL API I can
> refer to.  I suppose I could specify the object that Adam has started with
> in the File API draft, though).  Maybe more discussion is warranted at a
> venue like the TPAC.
>
> However, the revocation capability is pretty essential.  So this is
> something we'd have to add to the URL API.  And, the URL API has to be
> robust enough for both Stream and Blob use cases.
>
> Since Anne's suggestion is an important but late-breaking one, I'd propose
> tabling a CfC till the editor's draft accurately reflects consensus on what
> to do with URL generation and revocation for Blobs.  Maybe one thing we can
> do with existing implementation trains is:
>
> 1. Use vendor prefixing for create* and revoke* according to some rules [1]
> (since underscores are rarely used in DOM APIs, we'd have
> window.moz_createBlobURL() or chrome_createBlobURL( ) ), but I'd really like
> to hear from the Chromium folks.  Darin?  Others?
>
> 2. Adding revoke* to Adam's URL *or* create more versatile APIs that are
> better named within window* that account for Stream *and* Blob.
>
> A benefit *and* a drawback of reusing the URL object is that this would
> make Blob URLs and HTTP URLs within the same object.  It makes sense to
> revoke a Blob URL, but much less sense to revoke another URL.  The schemes
> are different, but they *do* behave pretty much similarly.
>
> I'd like a bit more implementer feedback, especially since doing 2. would
> be a pretty late breaking change.  I'm in favor of the best solution, but
> hate late breaking changes.  Chrome folks?
>
> -- A*
> [1]
> https://wiki.mozilla.org/Tantek-Mozilla-projects#DOM_API_vendor_prefixing
>
>

Re: createBlobURL

2010-10-18 Thread Arun Ranganathan


 On 10/18/10 12:16 PM, Anne van Kesteren wrote:
On Mon, 18 Oct 2010 18:09:24 +0200, Jonas Sicking  
wrote:

I would be ok with moz prefixing, though it would be nice to try to
find a solution pretty quickly if all this is is a discussion about
finding an appropriate name for this function.


Well, if people agree with me that the appropriate place would be the 
URL object -- assuming for now we are going to get that -- it would be 
more involved than just renaming.


Moving these features to the URL object is more complex, but may be 
desirable.  I'm not sure I can shoe horn that big an adjustment in time 
for the CfC (not least of all because there isn't a draft of the URL API 
I can refer to.  I suppose I could specify the object that Adam has 
started with in the File API draft, though).  Maybe more discussion is 
warranted at a venue like the TPAC.


However, the revocation capability is pretty essential.  So this is 
something we'd have to add to the URL API.  And, the URL API has to be 
robust enough for both Stream and Blob use cases.


Since Anne's suggestion is an important but late-breaking one, I'd 
propose tabling a CfC till the editor's draft accurately reflects 
consensus on what to do with URL generation and revocation for Blobs.  
Maybe one thing we can do with existing implementation trains is:


1. Use vendor prefixing for create* and revoke* according to some rules 
[1] (since underscores are rarely used in DOM APIs, we'd have 
window.moz_createBlobURL() or chrome_createBlobURL( ) ), but I'd really 
like to hear from the Chromium folks.  Darin?  Others?


2. Adding revoke* to Adam's URL *or* create more versatile APIs that are 
better named within window* that account for Stream *and* Blob.


A benefit *and* a drawback of reusing the URL object is that this would 
make Blob URLs and HTTP URLs within the same object.  It makes sense to 
revoke a Blob URL, but much less sense to revoke another URL.  The 
schemes are different, but they *do* behave pretty much similarly.


I'd like a bit more implementer feedback, especially since doing 2. 
would be a pretty late breaking change.  I'm in favor of the best 
solution, but hate late breaking changes.  Chrome folks?


-- A*
[1] 
https://wiki.mozilla.org/Tantek-Mozilla-projects#DOM_API_vendor_prefixing

Re: createBlobURL

On Mon, Oct 18, 2010 at 9:44 AM, Anne van Kesteren  wrote:
> On Mon, 18 Oct 2010 18:32:35 +0200, Jonas Sicking  wrote:
>>
>> What would the revoking API look like? Or are you saying that there
>> would be no way to get a string representation of the URL and instead
>> things like img.src should accept URL objects in addition to strings?
>
> I am not sure what the use case for revoking is, but that method can move to
> the URL object itself I suppose. (I would not want to modify everything to
> also accept URL objects by the way.)

Without revoking the UA has to keep around the URL-string -> resource
mapping for the lifetime of the page. Which in the world of web apps
can be a very long time. Even worse, in the case of dynamically
created blobs (blobbuilder, canvas.toFile/toBlob/getAsFile whatever
we'll call it), the resource has to stay around at least on the users
file system for the lifetime of the page.

/ Jonas

Re: createBlobURL


On Mon, 18 Oct 2010 18:32:35 +0200, Jonas Sicking  wrote:

What would the revoking API look like? Or are you saying that there
would be no way to get a string representation of the URL and instead
things like img.src should accept URL objects in addition to strings?


I am not sure what the use case for revoking is, but that method can move  
to the URL object itself I suppose. (I would not want to modify everything  
to also accept URL objects by the way.)



--
Anne van Kesteren
http://annevankesteren.nl/

Re: createBlobURL

On Mon, Oct 18, 2010 at 9:16 AM, Anne van Kesteren  wrote:
> On Mon, 18 Oct 2010 18:09:24 +0200, Jonas Sicking  wrote:
>>
>> I would be ok with moz prefixing, though it would be nice to try to
>> find a solution pretty quickly if all this is is a discussion about
>> finding an appropriate name for this function.
>
> Well, if people agree with me that the appropriate place would be the URL
> object -- assuming for now we are going to get that -- it would be more
> involved than just renaming.

What would the revoking API look like? Or are you saying that there
would be no way to get a string representation of the URL and instead
things like img.src should accept URL objects in addition to strings?

/ Jonas

Re: createBlobURL


On Mon, 18 Oct 2010 18:09:24 +0200, Jonas Sicking  wrote:

I would be ok with moz prefixing, though it would be nice to try to
find a solution pretty quickly if all this is is a discussion about
finding an appropriate name for this function.


Well, if people agree with me that the appropriate place would be the URL  
object -- assuming for now we are going to get that -- it would be more  
involved than just renaming.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: createBlobURL

On Mon, Oct 18, 2010 at 8:00 AM, Anne van Kesteren  wrote:

>>> Also, is there some kind of implementation summary available regarding
>>> the File API specifications? With what is shipping prefixed and what is
>>> shipping without a prefix? We are interested in supporting this too in the
>>> distant future.
>>
>> No, but there should be.   I think it's Firefox nightlies and Chromium
>> nightlies for now.  Firefox isn't using a prefix on the method.
>
> I would prefer it if createBlobURL and co were prefixed. Everything else is
> probably stable enough.

cc'ing Darin who knows more about the chrome implementation status
here. I was under the impression that they were even closer to
shipping this than we are.

I would be ok with moz prefixing, though it would be nice to try to
find a solution pretty quickly if all this is is a discussion about
finding an appropriate name for this function.

/ Jonas

Re: createBlobURL

On Mon, 18 Oct 2010 16:45:04 +0200, Arun Ranganathan
wrote:

On 10/18/10 10:14 AM, Anne van Kesteren wrote:

we design it in a generic way so that it also works for Stream objects?

This would be a good idea; this was noted as part of the issues [1].

Is your suggestion to have a generic method (with a better name) that
takes Streams or Blobs as arguments? Do you have a suggestion for
signature or method name?

I did not come further than createURL or createURLFromObject. However, if
we get URL objects (or maybe WebURL to prevent clashes) tying it to that
makes a lot of sense to me.

Otherwise we will get createStreamURL as well which seems kind of
unnecessary. Maybe even better, can we somehow converge this with the
URL specification Adam Barth was working on? So you can do new
URL(Blob) rather than having more methods on Window?

OK, that's engineering for maximum use cases, but not a bad idea on the
whole. However last I checked, the URL API was a proposal as a Google
doc[2]. Does it live somewhere more permanent?

No, not yet, but I suspect it would not be a problem for Adam to make this
into a Working Draft.

Implementations are already in circulation that have *.createBlobURL
which leads me to:

Also, is there some kind of implementation summary available regarding
the File API specifications? With what is shipping prefixed and what is
shipping without a prefix? We are interested in supporting this too in
the distant future.

No, but there should be. I think it's Firefox nightlies and Chromium
nightlies for now. Firefox isn't using a prefix on the method.

I would prefer it if createBlobURL and co were prefixed. Everything else
is probably stable enough.

-- A*
[1]
http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0083.html
[2]
https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en&pli=1#

--
Anne van Kesteren
http://annevankesteren.nl/

Re: createBlobURL

2010-10-18 Thread Arun Ranganathan

On 10/18/10 10:14 AM, Anne van Kesteren wrote:
On Mon, 18 Oct 2010 16:03:30 +0200, Arthur Barstow
wrote:
Arun and Jonas would like to publish a new Working Draft of the
File API spec and this is Call for Consensus to do so:

http://dev.w3.org/2006/webapi/FileAPI/

As with all of our CfCs, positive response is preferred and
encouraged and silence will be assumed to be assent.

The deadline for comments is October 22. This comment period is a bit
shorter than our typical 1-week review period but this will allow us
to sync the publication of this spec with the File API: {Writer,
Directories and System} specs. If this short comment period causes
any issues or concerns, please let us know.

I support publication, but [XHR2] is currently a broken link (misses a
# I think).

Duly noted. I'll fix this ASAP.

Also, if createBlobURL is the way to go -- rather than Blob.url -- can
we design it in a generic way so that it also works for Stream objects?

This would be a good idea; this was noted as part of the issues [1].

Is your suggestion to have a generic method (with a better name) that
takes Streams or Blobs as arguments? Do you have a suggestion for
signature or method name?

OK, that's engineering for maximum use cases, but not a bad idea on the
whole. However last I checked, the URL API was a proposal as a Google
doc[2]. Does it live somewhere more permanent? Implementations are
already in circulation that have *.createBlobURL which leads me to:

Also, is there some kind of implementation summary available regarding
the File API specifications? With what is shipping prefixed and what
is shipping without a prefix? We are interested in supporting this too
in the distant future.

No, but there should be. I think it's Firefox nightlies and Chromium
nightlies for now. Firefox isn't using a prefix on the method.

-- A*
[1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0083.html
[2]
https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en&pli=1#

createBlobURL (was: Re: CfC: WD of File API; deadline October 22)