Re: Discussion of File API at TPAC in Lyon
On Tuesday, November 16, 2010 8:11 AM, Jonas Sicking wrote:
On Tuesday, November 16, 2010, Anne van Kesteren ann...@opera.com
wrote:
On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking
jo...@sicking.cc
wrote:
Ok, here is what I'll propose as the final solution:
FileAPI will define the following WebIDL:
[Supplemental]
interface URL {
static DOMString createObjectURL(in Blob blob);
static void revokeObjectURL(in DOMString url);
};
[...]
Unless I hear otherwise from people, I'll assume that everyone is
happy with this.
This looks great. Will this make it into Firefox 4?
Assuming we can get everyone to agree quickly enough, yes.
We're okay with this too, especially if it doesn't change. :)
So it (soon) will be written, and so it will be done ;)
The only think I'm not sure about is the proposed spec language about
*prototype usage. But aside from that caveat, which I'll run by heycam, I'll
put the migration to URL in the editor's draft.
-- A*
Re: Discussion of File API at TPAC in Lyon
On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking jo...@sicking.cc wrote:
Ok, here is what I'll propose as the final solution:
FileAPI will define the following WebIDL:
[Supplemental]
interface URL {
static DOMString createObjectURL(in Blob blob);
static void revokeObjectURL(in DOMString url);
};
[...]
Unless I hear otherwise from people, I'll assume that everyone is
happy with this.
This looks great. Will this make it into Firefox 4?
--
Anne van Kesteren
http://annevankesteren.nl/
Re: Discussion of File API at TPAC in Lyon
On Tuesday, November 16, 2010, Anne van Kesteren ann...@opera.com wrote:
On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking jo...@sicking.cc wrote:
Ok, here is what I'll propose as the final solution:
FileAPI will define the following WebIDL:
[Supplemental]
interface URL {
static DOMString createObjectURL(in Blob blob);
static void revokeObjectURL(in DOMString url);
};
[...]
Unless I hear otherwise from people, I'll assume that everyone is
happy with this.
This looks great. Will this make it into Firefox 4?
Assuming we can get everyone to agree quickly enough, yes.
/ Jonas
Re: Discussion of File API at TPAC in Lyon
I have a clarifying question about how it would work:
How, if at all, the lifetime of the generated urls will be defined in case
of having those functions on URL interface object?
If those methods are on a global object, the lifetime of the urls created
would be gated by the lifetime of that global object, and in browser
implementations that lifetime is usually defined well - and used for other
things like lifetime of shared workers for example. There is certain times
when the document/page/window are 'closed and detached', and while it varies
in implementations and it is more complex then that, it provides a
well-understood lifetime boundary.
By having those methods on some static object, doesn't the lifetime becomes
unclear? Do we grab 'current context of the call'?
Dmitry
On Tue, Nov 16, 2010 at 8:10 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tuesday, November 16, 2010, Anne van Kesteren ann...@opera.com wrote:
On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking jo...@sicking.cc
wrote:
Ok, here is what I'll propose as the final solution:
FileAPI will define the following WebIDL:
[Supplemental]
interface URL {
static DOMString createObjectURL(in Blob blob);
static void revokeObjectURL(in DOMString url);
};
[...]
Unless I hear otherwise from people, I'll assume that everyone is
happy with this.
This looks great. Will this make it into Firefox 4?
Assuming we can get everyone to agree quickly enough, yes.
/ Jonas
Re: Discussion of File API at TPAC in Lyon
On Tue, Nov 16, 2010 at 10:42 AM, Dmitry Titov dim...@chromium.org wrote:
I have a clarifying question about how it would work:
How, if at all, the lifetime of the generated urls will be defined in case
of having those functions on URL interface object?
If those methods are on a global object, the lifetime of the urls created
would be gated by the lifetime of that global object, and in browser
implementations that lifetime is usually defined well - and used for other
things like lifetime of shared workers for example. There is certain times
when the document/page/window are 'closed and detached', and while it varies
in implementations and it is more complex then that, it provides a
well-understood lifetime boundary.
By having those methods on some static object, doesn't the lifetime becomes
unclear? Do we grab 'current context of the call'?
The intent (as i understand it) was to not change the lifetime
semantics that had been devised when these methods were defined at the
global scope, just to put a 'namespace' around them (so to speak). The
goal being a little less clutter the global namespace.
Dmitry
On Tue, Nov 16, 2010 at 8:10 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tuesday, November 16, 2010, Anne van Kesteren ann...@opera.com wrote:
On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking jo...@sicking.cc
wrote:
Ok, here is what I'll propose as the final solution:
FileAPI will define the following WebIDL:
[Supplemental]
interface URL {
static DOMString createObjectURL(in Blob blob);
static void revokeObjectURL(in DOMString url);
};
[...]
Unless I hear otherwise from people, I'll assume that everyone is
happy with this.
This looks great. Will this make it into Firefox 4?
Assuming we can get everyone to agree quickly enough, yes.
/ Jonas
Re: Discussion of File API at TPAC in Lyon
Thanks Michael,
so the proposed change is this: window.createObjectURL -
window.URL.createObjectURL
and it means it's also possible to do something like this:
var otherWindow = window.open(...)
otherWindow.URL.createObjectURL(...)
Is this correct understanding?
Dmitry
On Tue, Nov 16, 2010 at 11:57 AM, Michael Nordman micha...@google.comwrote:
On Tue, Nov 16, 2010 at 10:42 AM, Dmitry Titov dim...@chromium.org
wrote:
I have a clarifying question about how it would work:
How, if at all, the lifetime of the generated urls will be defined in
case
of having those functions on URL interface object?
If those methods are on a global object, the lifetime of the urls created
would be gated by the lifetime of that global object, and in browser
implementations that lifetime is usually defined well - and used for
other
things like lifetime of shared workers for example. There is certain
times
when the document/page/window are 'closed and detached', and while it
varies
in implementations and it is more complex then that, it provides a
well-understood lifetime boundary.
By having those methods on some static object, doesn't the lifetime
becomes
unclear? Do we grab 'current context of the call'?
The intent (as i understand it) was to not change the lifetime
semantics that had been devised when these methods were defined at the
global scope, just to put a 'namespace' around them (so to speak). The
goal being a little less clutter the global namespace.
Dmitry
On Tue, Nov 16, 2010 at 8:10 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tuesday, November 16, 2010, Anne van Kesteren ann...@opera.com
wrote:
On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking jo...@sicking.cc
wrote:
Ok, here is what I'll propose as the final solution:
FileAPI will define the following WebIDL:
[Supplemental]
interface URL {
static DOMString createObjectURL(in Blob blob);
static void revokeObjectURL(in DOMString url);
};
[...]
Unless I hear otherwise from people, I'll assume that everyone is
happy with this.
This looks great. Will this make it into Firefox 4?
Assuming we can get everyone to agree quickly enough, yes.
/ Jonas
Re: Discussion of File API at TPAC in Lyon
On Tue, Nov 16, 2010 at 10:42 AM, Dmitry Titov dim...@chromium.org wrote: I have a clarifying question about how it would work: How, if at all, the lifetime of the generated urls will be defined in case of having those functions on URL interface object? If those methods are on a global object, the lifetime of the urls created would be gated by the lifetime of that global object, and in browser implementations that lifetime is usually defined well - and used for other things like lifetime of shared workers for example. There is certain times when the document/page/window are 'closed and detached', and while it varies in implementations and it is more complex then that, it provides a well-understood lifetime boundary. By having those methods on some static object, doesn't the lifetime becomes unclear? Do we grab 'current context of the call'? We'll use the window object through which the URL object was retrieved. So for example: myurl1 = frames[0].URL.createObjectURL(blob); myurl2 = frames[1].URL.createObjectURL(blob); in this case lifetime of the two urls are bound to the lifetime of the two different windows. Does that make sense? This is similar to how base-uri resolving works in XMLHttpRequest where the base uri for a given XMLHttpRequest is determined by which constructor was used to create it, not based by who is calling .open or calling the constructor. / Jonas
Re: Discussion of File API at TPAC in Lyon
On Tue, Nov 16, 2010 at 12:07 PM, Dmitry Titov dim...@chromium.org wrote: Thanks Michael, so the proposed change is this: window.createObjectURL - window.URL.createObjectURL and it means it's also possible to do something like this: var otherWindow = window.open(...) otherWindow.URL.createObjectURL(...) Is this correct understanding? If you do this, then the lifetime of the URL is the lifetime of the Document in otherWindow. Actually since at the time you're calling createObjectURL otherWindow still contains an about:blank document, as soon as the url passed to window.open is loaded, the returned URL will expire. / Jonas
Re: Discussion of File API at TPAC in Lyon
On Tue, Nov 16, 2010 at 12:20 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 16, 2010 at 12:07 PM, Dmitry Titov dim...@chromium.org wrote: Thanks Michael, so the proposed change is this: window.createObjectURL - window.URL.createObjectURL and it means it's also possible to do something like this: var otherWindow = window.open(...) otherWindow.URL.createObjectURL(...) Is this correct understanding? If you do this, then the lifetime of the URL is the lifetime of the Document in otherWindow. Actually since at the time you're calling createObjectURL otherWindow still contains an about:blank document, as soon as the url passed to window.open is loaded, the returned URL will expire. That makes perfect sense, thanks!
RE: Discussion of File API at TPAC in Lyon
On Tuesday, November 16, 2010 8:11 AM, Jonas Sicking wrote:
On Tuesday, November 16, 2010, Anne van Kesteren ann...@opera.com
wrote:
On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking jo...@sicking.cc
wrote:
Ok, here is what I'll propose as the final solution:
FileAPI will define the following WebIDL:
[Supplemental]
interface URL {
static DOMString createObjectURL(in Blob blob);
static void revokeObjectURL(in DOMString url);
};
[...]
Unless I hear otherwise from people, I'll assume that everyone is
happy with this.
This looks great. Will this make it into Firefox 4?
Assuming we can get everyone to agree quickly enough, yes.
We're okay with this too, especially if it doesn't change. :)
Re: Discussion of File API at TPAC in Lyon
On Sun, Nov 14, 2010 at 8:32 AM, Cameron McCormack c...@mcc.id.au wrote:
Jonas Sicking:
Since I wrote the IDL for indexeddb above, WebIDL has gotten support
for static which should do what we want. Though it's a bit unclear
if using a real interface would cause there to be a .prototype
property on the URL interface which we for now don't want, right. It's
also unclear if static functions appear on URL objects as well.
The new static keyword will cause the function property to exist on the
interface object and not on the prototype. Thus you can’t access the
function directly by getting a property on an instance of the interface.
Ok, here is what I'll propose as the final solution:
FileAPI will define the following WebIDL:
[Supplemental]
interface URL {
static DOMString createObjectURL(in Blob blob);
static void revokeObjectURL(in DOMString url);
};
It will also contain the following normative text:
ECMAScript implementations of this specification MUST ensure that they
do not expose a codeprototype/code property on the URL interface
object unless the implementation also implements the [URL]
specification. In other words, the following expression
codeURL.prototype/code MUST evaluate to true if the implementation
implements the [URL] specification, and MUST NOT evaluate to true
otherwise.
I'll also talk with Adam Barth and encourage the following text in the
URL specification:
Users of this API are encouraged to feature test by checking codeif
(URL URL.prototype) { .../code. Otherwise there is a risk that
implementations which implement the [File API] specification, but not
this specification, will pass the feature test.
Unless I hear otherwise from people, I'll assume that everyone is
happy with this.
/ Jonas
Re: Discussion of File API at TPAC in Lyon
Jonas Sicking: Since I wrote the IDL for indexeddb above, WebIDL has gotten support for static which should do what we want. Though it's a bit unclear if using a real interface would cause there to be a .prototype property on the URL interface which we for now don't want, right. It's also unclear if static functions appear on URL objects as well. The new static keyword will cause the function property to exist on the interface object and not on the prototype. Thus you can’t access the function directly by getting a property on an instance of the interface. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Discussion of File API at TPAC in Lyon
On Sat, 13 Nov 2010 03:09:50 +0100, Jonas Sicking jo...@sicking.cc wrote: If everyone is fine with this then I am too. Does this mean the functions will also exist on URL objects? Or just on URL interface objects? How does this work in Web IDL? (The concept seems fine to me, just curious.) -- Anne van Kesteren http://annevankesteren.nl/
Re: Discussion of File API at TPAC in Lyon
On Sat, Nov 13, 2010 at 2:33 AM, Anne van Kesteren ann...@opera.com wrote: On Sat, 13 Nov 2010 03:09:50 +0100, Jonas Sicking jo...@sicking.cc wrote: If everyone is fine with this then I am too. Does this mean the functions will also exist on URL objects? Not unless we want them to. Or just on URL interface objects? That's how I've defined it in IndexedDB. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#idl-def-IDBKeyRangeConstructors How does this work in Web IDL? (The concept seems fine to me, just curious.) Since I wrote the IDL for indexeddb above, WebIDL has gotten support for static which should do what we want. Though it's a bit unclear if using a real interface would cause there to be a .prototype property on the URL interface which we for now don't want, right. It's also unclear if static functions appear on URL objects as well. cc'ing Cameron for enlightenment. / Jonas
Re: Discussion of File API at TPAC in Lyon
On Thu, 11 Nov 2010 22:06:59 +0100, Arun Ranganathan aranganat...@mozilla.com wrote: If we're going to keep both functions around, then it's honestly not *that much* of an improvement to move them from window* to document*, is it? Polluting the global object less is always a win. In this case, since we're going to add something to HTMLImageElement, why not leave createObjectURL and revokeObject URL well alone as part of window*? These seem like separate issues. So it looks like we'll add a [Supplemental] to interfaces like HTMLImageElement allowing them to take a src object, and we can then define *that* src object to accomodate Stream and Blob use case scenarios. I'm amenable to first introducing that extension to HTMLImageElement in File API if everyone else is :) It is probably better to do this directly in HTML5. -- Anne van Kesteren http://annevankesteren.nl/
RE: Discussion of File API at TPAC in Lyon
On Thursday, November 11, 2010 11:47 AM, Jonas Sicking wrote: Oh, definitely, we still need the createObjectURL/revokeObjectURL functions. Sorry, that was probably unclear. However we're still left without a place to put them. Maybe it's as simple as putting them on the document object? That works nicely since their lifetime is scoped to that of the document object. Another possibility is putting them on the URL interface object. I.e. not using URL objects themselves, but rather something like this: x = URL.createObjectURL(myblock); typeof x == string; URL.revokeObjectURL(x); But I think I prefer the document solution. I thought we'd decided on a new global object and just needed to come up with a name. This is what we're currently planning to do. Mostly though, I just want us to decide. This seems to have changed every month for a long time and I'd like us to pick a solution and stick to it. From http://www.w3.org/2010/11/02-webapps-minutes.html#item16 jonas: the proposed solution is some global object where we put 2 functions anne: is there some existing place we could put them? sam: maybe window.blob? but you want to do it for stream too so maybe that's not a good place ericu and others: k, let's move on
Re: Discussion of File API at TPAC in Lyon
On Fri, Nov 12, 2010 at 3:38 PM, Adrian Bateman adria...@microsoft.com wrote: On Thursday, November 11, 2010 11:47 AM, Jonas Sicking wrote: Oh, definitely, we still need the createObjectURL/revokeObjectURL functions. Sorry, that was probably unclear. However we're still left without a place to put them. Maybe it's as simple as putting them on the document object? That works nicely since their lifetime is scoped to that of the document object. Another possibility is putting them on the URL interface object. I.e. not using URL objects themselves, but rather something like this: x = URL.createObjectURL(myblock); typeof x == string; URL.revokeObjectURL(x); But I think I prefer the document solution. I thought we'd decided on a new global object and just needed to come up with a name. This is what we're currently planning to do. Mostly though, I just want us to decide. This seems to have changed every month for a long time and I'd like us to pick a solution and stick to it. From http://www.w3.org/2010/11/02-webapps-minutes.html#item16 jonas: the proposed solution is some global object where we put 2 functions anne: is there some existing place we could put them? sam: maybe window.blob? but you want to do it for stream too so maybe that's not a good place ericu and others: k, let's move on I don't actually remember how the discussion went. I do remember that I was confused for a while thinking that we needed a new global anyway, to allow Files, Blobs etc to be used directly on img.src, but I was wrong in that. Anyhow, I agree with the sentiment that I'd like to just decide a place and move on with our lives :) Maybe using a global object is better since we don't really want these functions to appear on documents created using XMLHttpRequest, DOMParser, etc. Quick, someone suggest a name, whoever comes up with one first wins a beer for next TPAC :) / Jonas
Re: Discussion of File API at TPAC in Lyon
On Fri, Nov 12, 2010 at 3:47 PM, Jonas Sicking jo...@sicking.cc wrote: Maybe using a global object is better since we don't really want these functions to appear on documents created using XMLHttpRequest, DOMParser, etc. Quick, someone suggest a name, whoever comes up with one first wins a beer for next TPAC :) I think that whoever suggested URL already wins that beer. ^_^ ~TJ
Re: Discussion of File API at TPAC in Lyon
On Fri, Nov 12, 2010 at 5:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Nov 12, 2010 at 3:47 PM, Jonas Sicking jo...@sicking.cc wrote: Maybe using a global object is better since we don't really want these functions to appear on documents created using XMLHttpRequest, DOMParser, etc. Quick, someone suggest a name, whoever comes up with one first wins a beer for next TPAC :) I think that whoever suggested URL already wins that beer. ^_^ I guess me and Anne will have to split it then, since he proposed using the URL constructor, and I said that I didn't like using the constructor but suggested putting the functions on the URL interface object. Though it's quite possible that someone beat me to that proposal, in which case they better speak up or loose a beer forever :-) The downside of using URL though is that both Firefox and IE, and I think Chrome too, seems to be ready to ship createObjectURL/revokeObjectURL very soon, much sooner than the URL object will be fully specified. That means that if we set up the URL interface object for createObjectURL/revokeObjectURL, then it'll be harder to feature detect support for the real URL object. Other than that I'd be happy to use URL. / Jonas
Re: Discussion of File API at TPAC in Lyon
On Fri, Nov 12, 2010 at 5:54 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Nov 12, 2010 at 5:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Nov 12, 2010 at 3:47 PM, Jonas Sicking jo...@sicking.cc wrote: Maybe using a global object is better since we don't really want these functions to appear on documents created using XMLHttpRequest, DOMParser, etc. Quick, someone suggest a name, whoever comes up with one first wins a beer for next TPAC :) I think that whoever suggested URL already wins that beer. ^_^ I guess me and Anne will have to split it then, since he proposed using the URL constructor, and I said that I didn't like using the constructor but suggested putting the functions on the URL interface object. Though it's quite possible that someone beat me to that proposal, in which case they better speak up or loose a beer forever :-) The downside of using URL though is that both Firefox and IE, and I think Chrome too, seems to be ready to ship createObjectURL/revokeObjectURL very soon, much sooner than the URL object will be fully specified. That means that if we set up the URL interface object for createObjectURL/revokeObjectURL, then it'll be harder to feature detect support for the real URL object. Only marginally. There'll be properties on URL that can be existence-tested for in the future. ~TJ
Re: Discussion of File API at TPAC in Lyon
On Fri, Nov 12, 2010 at 5:58 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Nov 12, 2010 at 5:54 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Nov 12, 2010 at 5:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Nov 12, 2010 at 3:47 PM, Jonas Sicking jo...@sicking.cc wrote: Maybe using a global object is better since we don't really want these functions to appear on documents created using XMLHttpRequest, DOMParser, etc. Quick, someone suggest a name, whoever comes up with one first wins a beer for next TPAC :) I think that whoever suggested URL already wins that beer. ^_^ I guess me and Anne will have to split it then, since he proposed using the URL constructor, and I said that I didn't like using the constructor but suggested putting the functions on the URL interface object. Though it's quite possible that someone beat me to that proposal, in which case they better speak up or loose a beer forever :-) The downside of using URL though is that both Firefox and IE, and I think Chrome too, seems to be ready to ship createObjectURL/revokeObjectURL very soon, much sooner than the URL object will be fully specified. That means that if we set up the URL interface object for createObjectURL/revokeObjectURL, then it'll be harder to feature detect support for the real URL object. Only marginally. There'll be properties on URL that can be existence-tested for in the future. Just to make implications clear to everyone. It means that you'll have to feature detect URL by doing: if (URL protocol in URL.prototype) you can't do if (URL URL.prototype.protocol) since that will call the protocol getter with a this object set to something other than a real URL instance and thus throw. Alternatively, if all implementations are careful to not make URL a constructor for now, the test will be if (URL URL.prototype) If everyone is fine with this then I am too. / Jonas
Re: Discussion of File API at TPAC in Lyon
On Thu, Nov 11, 2010 at 8:52 AM, Arun Ranganathan
aranganat...@mozilla.com wrote:
At the recent Technical Plenary and All WG Meetings in Lyon, File API[1] was
discussed, and there are some take away action items that I minuted for
myself for File API, but I'm not sure they are reflected in ACTION items,
etc. From my own notes:
Essentially, strong opinions were voiced against having top-level methods
createObjectURL and revokeObjectURL. So the biggest change was to introduce a
new top-level object (ObjectURL) which would have methods to obtain a string
Blob URI. This removes the need for a revocation mechanism, since now the
ObjectURL object (which would take as a constructor the Blob object) would
oversee lifetime issues. This is a big change, but potentially one that
allows us to work with the emerging URL API (which hopefully is going
somewhere).
Actually, this was a brain-fart on my part. What was suggested was
that we simply allow:
img.src = myFile;
img.src = myBlob;
img.src = myFutureStream;
img.src = http://www.sweden.se/ABBA.jpg;;
These things could be implemented without lifetime worries.
What we might need is a IDL construct so that a specification can just say
interface HTMLImageElement {
...
attribute URLThingamajig src;
...
};
Which would automatically define that it accepts files/blobs/strings.
And gives us a central place to update when we want to add streams and
other things.
/ Jonas
Re: Discussion of File API at TPAC in Lyon
On Thu, Nov 11, 2010 at 8:52 AM, Arun Ranganathan aranganat...@mozilla.com wrote: At the recent Technical Plenary and All WG Meetings in Lyon, File API[1] was discussed, and there are some take away action items that I minuted for myself for File API, but I'm not sure they are reflected in ACTION items, etc. From my own notes: Essentially, strong opinions were voiced against having top-level methods createObjectURL and revokeObjectURL. So the biggest change was to introduce a new top-level object (ObjectURL) which would have methods to obtain a string Blob URI. This removes the need for a revocation mechanism, since now the ObjectURL object (which would take as a constructor the Blob object) would oversee lifetime issues. This is a big change, but potentially one that allows us to work with the emerging URL API (which hopefully is going somewhere). While I agree that we came up with the new top-level object [called the dummy object in the minutes] to hold createObjectURL and revokeObjectURL, I don't think we actually threw away the second method. It would still be useful to be able to throw away Blob URLs explicitly, so as to avoid keeping the Blobs around forever in long-lived windows. Also, I believe we decided that this should be disjoint from the URL object that abarth is speccing: arun: is it worth make global dummy object the same thing being specced by adam barth no jonas: abarth's thing is to solve parsing urls. this isn't want we need to do with blob urls anne: not so sure jonas: there's a vague resemblance given that they both revolve around URLs sam: agrees ... especially since adam's thing doens't exist yet Checking again, my interpretation of the minutes is the same as my memory, so I can't possibly be mistaken ;'. There were additional discussions about Content-Disposition and further headers introduced to Blob URIs, but we agreed that this should go to the listserv for further discussion. The question of *further* HTTP-like behaviors on Blob URIs is still open for discussion. Notably, Content-Disposition is desired for download management, but using a header to toggle browser behavior seems a bit arbitrary, and there may be better ways to approach the issue. Yeah, I think we made some good progress there, but no conclusions. I'll start another thread about the headers. While I look forward to the minutes from the WebApps meeting, does anyone in attendance agree or disagree that these are the main points to take away, or wish to add something else? Note that at least two implementations are around the corner with window.createObjectURL and window.revokeObjectURL. Vendor prefixing is a viable option in the mean time. -- A* [1] http://www.w3.org/TR/FileAPI/
Re: Discussion of File API at TPAC in Lyon
On Thu, Nov 11, 2010 at 10:02 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Nov 11, 2010 at 8:52 AM, Arun Ranganathan
aranganat...@mozilla.com wrote:
At the recent Technical Plenary and All WG Meetings in Lyon, File API[1] was
discussed, and there are some take away action items that I minuted for
myself for File API, but I'm not sure they are reflected in ACTION items,
etc. From my own notes:
Essentially, strong opinions were voiced against having top-level methods
createObjectURL and revokeObjectURL. So the biggest change was to introduce
a new top-level object (ObjectURL) which would have methods to obtain a
string Blob URI. This removes the need for a revocation mechanism, since
now the ObjectURL object (which would take as a constructor the Blob object)
would oversee lifetime issues. This is a big change, but potentially one
that allows us to work with the emerging URL API (which hopefully is going
somewhere).
Actually, this was a brain-fart on my part. What was suggested was
that we simply allow:
img.src = myFile;
img.src = myBlob;
img.src = myFutureStream;
img.src = http://www.sweden.se/ABBA.jpg;;
These things could be implemented without lifetime worries.
What we might need is a IDL construct so that a specification can just say
interface HTMLImageElement {
...
attribute URLThingamajig src;
...
};
Which would automatically define that it accepts files/blobs/strings.
And gives us a central place to update when we want to add streams and
other things.
While this is a clean API, it doesn't work for passing URLs to
plugins, and it doesn't work when folks construct a bunch of DOM via
innerHTML. And if you add a way to get a string from one of these
objects, you're back with the lifetime problem again.
Re: Discussion of File API at TPAC in Lyon
On Thu, Nov 11, 2010 at 11:18 AM, Eric Uhrhane er...@google.com wrote:
On Thu, Nov 11, 2010 at 10:02 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Nov 11, 2010 at 8:52 AM, Arun Ranganathan
aranganat...@mozilla.com wrote:
At the recent Technical Plenary and All WG Meetings in Lyon, File API[1]
was discussed, and there are some take away action items that I minuted for
myself for File API, but I'm not sure they are reflected in ACTION items,
etc. From my own notes:
Essentially, strong opinions were voiced against having top-level methods
createObjectURL and revokeObjectURL. So the biggest change was to introduce
a new top-level object (ObjectURL) which would have methods to obtain a
string Blob URI. This removes the need for a revocation mechanism, since
now the ObjectURL object (which would take as a constructor the Blob
object) would oversee lifetime issues. This is a big change, but
potentially one that allows us to work with the emerging URL API (which
hopefully is going somewhere).
Actually, this was a brain-fart on my part. What was suggested was
that we simply allow:
img.src = myFile;
img.src = myBlob;
img.src = myFutureStream;
img.src = http://www.sweden.se/ABBA.jpg;;
These things could be implemented without lifetime worries.
What we might need is a IDL construct so that a specification can just say
interface HTMLImageElement {
...
attribute URLThingamajig src;
...
};
Which would automatically define that it accepts files/blobs/strings.
And gives us a central place to update when we want to add streams and
other things.
While this is a clean API, it doesn't work for passing URLs to
plugins, and it doesn't work when folks construct a bunch of DOM via
innerHTML. And if you add a way to get a string from one of these
objects, you're back with the lifetime problem again.
Oh, definitely, we still need the createObjectURL/revokeObjectURL
functions. Sorry, that was probably unclear.
However we're still left without a place to put them. Maybe it's as
simple as putting them on the document object? That works nicely since
their lifetime is scoped to that of the document object.
Another possibility is putting them on the URL interface object. I.e.
not using URL objects themselves, but rather something like this:
x = URL.createObjectURL(myblock);
typeof x == string;
URL.revokeObjectURL(x);
But I think I prefer the document solution.
/ Jonas
/ Jonas
Re: Discussion of File API at TPAC in Lyon
On Nov/11/2010 11:52 AM, ext Arun Ranganathan wrote: While I look forward to the minutes from the WebApps meeting, The minutes from File* discussion are: http://www.w3.org/2010/11/02-webapps-minutes.html#item16 http://www.w3.org/2010/11/02-webapps-minutes.html#item17 -AB
Re: Discussion of File API at TPAC in Lyon
On Thu, Nov 11, 2010 at 11:18 AM, Eric Uhrhane er...@google.com
wrote:
On Thu, Nov 11, 2010 at 10:02 AM, Jonas Sicking jo...@sicking.cc
wrote:
On Thu, Nov 11, 2010 at 8:52 AM, Arun Ranganathan
aranganat...@mozilla.com wrote:
At the recent Technical Plenary and All WG Meetings in Lyon, File
API[1] was discussed, and there are some take away action items
that I minuted for myself for File API, but I'm not sure they are
reflected in ACTION items, etc. From my own notes:
Essentially, strong opinions were voiced against having top-level
methods createObjectURL and revokeObjectURL. So the biggest change
was to introduce a new top-level object (ObjectURL) which would
have methods to obtain a string Blob URI. This removes the need
for a revocation mechanism, since now the ObjectURL object (which
would take as a constructor the Blob object) would oversee
lifetime issues. This is a big change, but potentially one that
allows us to work with the emerging URL API (which hopefully is
going somewhere).
Actually, this was a brain-fart on my part. What was suggested was
that we simply allow:
img.src = myFile;
img.src = myBlob;
img.src = myFutureStream;
img.src = http://www.sweden.se/ABBA.jpg;;
These things could be implemented without lifetime worries.
What we might need is a IDL construct so that a specification can
just say
interface HTMLImageElement {
...
attribute URLThingamajig src;
...
};
Which would automatically define that it accepts
files/blobs/strings.
And gives us a central place to update when we want to add streams
and
other things.
While this is a clean API, it doesn't work for passing URLs to
plugins, and it doesn't work when folks construct a bunch of DOM via
innerHTML. And if you add a way to get a string from one of these
objects, you're back with the lifetime problem again.
Oh, definitely, we still need the createObjectURL/revokeObjectURL
functions. Sorry, that was probably unclear.
However we're still left without a place to put them. Maybe it's as
simple as putting them on the document object? That works nicely since
their lifetime is scoped to that of the document object.
If we're going to keep both functions around, then it's honestly not *that
much* of an improvement to move them from window* to document*, is it? In this
case, since we're going to add something to HTMLImageElement, why not leave
createObjectURL and revokeObject URL well alone as part of window*?
So it looks like we'll add a [Supplemental] to interfaces like HTMLImageElement
allowing them to take a src object, and we can then define *that* src object
to accomodate Stream and Blob use case scenarios. I'm amenable to first
introducing that extension to HTMLImageElement in File API if everyone else is
:)
-- A*
Re: Discussion of File API at TPAC in Lyon
On Thu, Nov 11, 2010 at 1:06 PM, Arun Ranganathan
aranganat...@mozilla.com wrote:
On Thu, Nov 11, 2010 at 11:18 AM, Eric Uhrhane er...@google.com
wrote:
On Thu, Nov 11, 2010 at 10:02 AM, Jonas Sicking jo...@sicking.cc
wrote:
On Thu, Nov 11, 2010 at 8:52 AM, Arun Ranganathan
aranganat...@mozilla.com wrote:
At the recent Technical Plenary and All WG Meetings in Lyon, File
API[1] was discussed, and there are some take away action items
that I minuted for myself for File API, but I'm not sure they are
reflected in ACTION items, etc. From my own notes:
Essentially, strong opinions were voiced against having top-level
methods createObjectURL and revokeObjectURL. So the biggest change
was to introduce a new top-level object (ObjectURL) which would
have methods to obtain a string Blob URI. This removes the need
for a revocation mechanism, since now the ObjectURL object (which
would take as a constructor the Blob object) would oversee
lifetime issues. This is a big change, but potentially one that
allows us to work with the emerging URL API (which hopefully is
going somewhere).
Actually, this was a brain-fart on my part. What was suggested was
that we simply allow:
img.src = myFile;
img.src = myBlob;
img.src = myFutureStream;
img.src = http://www.sweden.se/ABBA.jpg;;
These things could be implemented without lifetime worries.
What we might need is a IDL construct so that a specification can
just say
interface HTMLImageElement {
...
attribute URLThingamajig src;
...
};
Which would automatically define that it accepts
files/blobs/strings.
And gives us a central place to update when we want to add streams
and
other things.
While this is a clean API, it doesn't work for passing URLs to
plugins, and it doesn't work when folks construct a bunch of DOM via
innerHTML. And if you add a way to get a string from one of these
objects, you're back with the lifetime problem again.
Oh, definitely, we still need the createObjectURL/revokeObjectURL
functions. Sorry, that was probably unclear.
However we're still left without a place to put them. Maybe it's as
simple as putting them on the document object? That works nicely since
their lifetime is scoped to that of the document object.
If we're going to keep both functions around, then it's honestly not *that
much* of an improvement to move them from window* to document*, is it? In
this case, since we're going to add something to HTMLImageElement, why not
leave createObjectURL and revokeObject URL well alone as part of window*?
I think the concern is that functions on window can collide with
javascript functions that webpages can define. I.e. there's a risk
that there are pages out there with code like:
function createObjectURL(x, y, z) {
doSomethingCompletelyUnrelatedToBlobs(z, x + y);
}
So it looks like we'll add a [Supplemental] to interfaces like
HTMLImageElement allowing them to take a src object, and we can then define
*that* src object to accomodate Stream and Blob use case scenarios. I'm
amenable to first introducing that extension to HTMLImageElement in File API
if everyone else is :)
I'd be fine with that, but might also be easy to ask that this is
added to the HTML5 spec.
/ Jonas
