subject:"createBlobURL"

On Mon, Oct 25, 2010 at 6:09 AM, Anne van Kesteren ann...@opera.com wrote:
 On Thu, 21 Oct 2010 19:47:08 +0200, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, Oct 21, 2010 at 3:50 AM, Anne van Kesteren ann...@opera.com
 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 imgs 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

On Mon, Oct 25, 2010 at 4:48 PM, Jonas Sicking jo...@sicking.cc 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 http://dev.w3.org/csswg/css3-images/.

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 5:04 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Mon, Oct 25, 2010 at 4:48 PM, Jonas Sicking jo...@sicking.cc 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 http://dev.w3.org/csswg/css3-images/.

 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 5:51 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Mon, Oct 25, 2010 at 5:04 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Mon, Oct 25, 2010 at 4:48 PM, Jonas Sicking jo...@sicking.cc 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 http://dev.w3.org/csswg/css3-images/.

 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 url interface, and would be accepted
anywhere a url 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:56 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Mon, Oct 25, 2010 at 5:51 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Mon, Oct 25, 2010 at 5:04 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Mon, Oct 25, 2010 at 4:48 PM, Jonas Sicking jo...@sicking.cc 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 http://dev.w3.org/csswg/css3-images/.

 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 url interface, and would be accepted
 anywhere a url 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 image rather than url
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 http://dev.w3.org/csswg/css3-images/

/ Jonas

Re: createBlobURL

On Mon, Oct 25, 2010 at 5:59 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Mon, Oct 25, 2010 at 5:56 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Mon, Oct 25, 2010 at 5:51 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Mon, Oct 25, 2010 at 5:04 PM, Tab Atkins Jr. jackalm...@gmail.com 
 wrote:
 On Mon, Oct 25, 2010 at 4:48 PM, Jonas Sicking jo...@sicking.cc 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 http://dev.w3.org/csswg/css3-images/.

 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 url interface, and would be accepted
 anywhere a url 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 image rather than url
 above.

No, I meant url, which happens to be a type of image as well.  I
don't know what it would mean for me to mean image, 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 http://dev.w3.org/csswg/css3-images/

I outlined how it would work above, I thought.  Any property that can
take a url should, in the Values API, be able to take a url object
like we're describing here.  Any function that can take a url 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 url.

~TJ

Re: createBlobURL

On Mon, Oct 25, 2010 at 6:10 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Mon, Oct 25, 2010 at 5:59 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Mon, Oct 25, 2010 at 5:56 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Mon, Oct 25, 2010 at 5:51 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Mon, Oct 25, 2010 at 5:04 PM, Tab Atkins Jr. jackalm...@gmail.com 
 wrote:
 On Mon, Oct 25, 2010 at 4:48 PM, Jonas Sicking jo...@sicking.cc 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 http://dev.w3.org/csswg/css3-images/.

 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 url interface, and would be accepted
 anywhere a url 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 image rather than url
 above.

 No, I meant url, which happens to be a type of image as well.  I
 don't know what it would mean for me to mean image, 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 http://dev.w3.org/csswg/css3-images/

 I outlined how it would work above, I thought.  Any property that can
 take a url should, in the Values API, be able to take a url object
 like we're describing here.  Any function that can take a url 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 url.

The question is, how do you use a DOMURL together with all the other
features of image. 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 7:48 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Mon, Oct 25, 2010 at 6:10 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Mon, Oct 25, 2010 at 5:59 PM, Jonas Sicking jo...@sicking.cc 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 http://dev.w3.org/csswg/css3-images/

 I outlined how it would work above, I thought.  Any property that can
 take a url should, in the Values API, be able to take a url object
 like we're describing here.  Any function that can take a url 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 url.

 The question is, how do you use a DOMURL together with all the other
 features of image. 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

2010-10-21 Thread Anne van Kesteren


On Wed, 20 Oct 2010 01:57:30 +0200, Jonas Sicking jo...@sicking.cc 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-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 jo...@sicking.cc 
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 Jonas Sicking

On Thu, Oct 21, 2010 at 3:50 AM, Anne van Kesteren ann...@opera.com wrote:
 On Wed, 20 Oct 2010 01:57:30 +0200, Jonas Sicking jo...@sicking.cc 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-20 Thread Darin Fisher

On Tue, Oct 19, 2010 at 4:57 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Tue, Oct 19, 2010 at 1:24 AM, Anne van Kesteren ann...@opera.com
 wrote:
  On Mon, 18 Oct 2010 20:15:53 +0200, Jonas Sicking jo...@sicking.cc
 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 Anne van Kesteren


On Tue, 19 Oct 2010 02:30:39 +0200, Jonas Sicking jo...@sicking.cc 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-19 Thread Anne van Kesteren


On Mon, 18 Oct 2010 20:15:53 +0200, Jonas Sicking jo...@sicking.cc 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 Arun Ranganathan


 On 10/19/10 4:20 AM, Anne van Kesteren wrote:
On Tue, 19 Oct 2010 02:30:39 +0200, Jonas Sicking jo...@sicking.cc 
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 Jonas Sicking

On Tue, Oct 19, 2010 at 1:24 AM, Anne van Kesteren ann...@opera.com wrote:
 On Mon, 18 Oct 2010 20:15:53 +0200, Jonas Sicking jo...@sicking.cc 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 Jonas Sicking

On Tue, Oct 19, 2010 at 1:20 AM, Anne van Kesteren ann...@opera.com wrote:
 On Tue, 19 Oct 2010 02:30:39 +0200, Jonas Sicking jo...@sicking.cc 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

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

On Mon, 18 Oct 2010 16:03:30 +0200, Arthur Barstow art.bars...@nokia.com  
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).


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



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.



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

On 10/18/10 10:14 AM, Anne van Kesteren wrote:
On Mon, 18 Oct 2010 16:03:30 +0200, Arthur Barstow
art.bars...@nokia.com 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?

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? 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-t7lZgzisTuGTXkdzAk4gLUhl=enpli=1#

Re: createBlobURL

On Mon, 18 Oct 2010 16:45:04 +0200, Arun Ranganathan a...@mozilla.com
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.

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-t7lZgzisTuGTXkdzAk4gLUhl=enpli=1#

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

Re: createBlobURL

On Mon, Oct 18, 2010 at 8:00 AM, Anne van Kesteren ann...@opera.com 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 18:09:24 +0200, Jonas Sicking jo...@sicking.cc 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 9:16 AM, Anne van Kesteren ann...@opera.com wrote:
 On Mon, 18 Oct 2010 18:09:24 +0200, Jonas Sicking jo...@sicking.cc 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:32:35 +0200, Jonas Sicking jo...@sicking.cc 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:44 AM, Anne van Kesteren ann...@opera.com wrote:
 On Mon, 18 Oct 2010 18:32:35 +0200, Jonas Sicking jo...@sicking.cc 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

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 jo...@sicking.cc 
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 a...@mozilla.com wrote:

  On 10/18/10 12:16 PM, Anne van Kesteren wrote:

 On Mon, 18 Oct 2010 18:09:24 +0200, Jonas Sicking jo...@sicking.cc
 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