Re: File URN lifetimes and SharedWorkers
On Fri, Jul 23, 2010 at 12:15 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 23 Feb 2010, Drew Wilson wrote: This was recently brought to my attention by one of the web app developers in my office: http://dev.w3.org/2006/webapi/FileAPI/#lifeTime User agents MUST ensure that the lifetime of File URN #dfn-fileURNs is the same as the lifetime of the Document [HTML5 #HTML5] of the origin script which spawned the File #dfn-file object on which the urn #dfn-urn attribute was called. When this Document is destroyed, implementations MUST treat requests for File URN #dfn-fileURNs created within thisDocument as 404 Not Found.[Processing Model #processing-model-urn for File URN #dfn-fileURN s] I'm curious how this should work for SharedWorkers - let's imagine that I create a File object in a document and send it to a SharedWorker via postMessage() - the SharedWorker will receive a structured clone of that File object, which it can then access. What should the lifetime of the resulting URN for that file object be? I suspect the intent is that File objects ought to be tied to an owning script context rather than to a specific Document (so, in this case, the lifetime of the resulting URN would be the lifetime of the worker)? Was this ever addressed? Do I need to add something to the workers spec for this? Who is currently editing the File API specs? There is a relevant discussion here: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0169.html Looks like adding an explicit createBlobUrl/revokeBlobUrl on global object, and tying the lifetime to this global object as well (implicit revoke) can be less confusing then current spec language. Arun Ranganathan is editor and Jonas Sicking seems to be a co-editor. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: File URN lifetimes and SharedWorkers
On Fri, Jul 23, 2010 at 12:15 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 23 Feb 2010, Drew Wilson wrote: This was recently brought to my attention by one of the web app developers in my office: http://dev.w3.org/2006/webapi/FileAPI/#lifeTime User agents MUST ensure that the lifetime of File URN #dfn-fileURNs is the same as the lifetime of the Document [HTML5 #HTML5] of the origin script which spawned the File #dfn-file object on which the urn #dfn-urn attribute was called. When this Document is destroyed, implementations MUST treat requests for File URN #dfn-fileURNs created within thisDocument as 404 Not Found.[Processing Model #processing-model-urn for File URN #dfn-fileURN s] I'm curious how this should work for SharedWorkers - let's imagine that I create a File object in a document and send it to a SharedWorker via postMessage() - the SharedWorker will receive a structured clone of that File object, which it can then access. What should the lifetime of the resulting URN for that file object be? I suspect the intent is that File objects ought to be tied to an owning script context rather than to a specific Document (so, in this case, the lifetime of the resulting URN would be the lifetime of the worker)? Was this ever addressed? Do I need to add something to the workers spec for this? Who is currently editing the File API specs? This is indeed a tricky situations given that, as I understand it, the lifetime of a shared worker is pretty fuzzy. I think the best we can do is to say that a File.url extracted from a shared worker remains working as long as the shared worker stays alive. I.e. as long as |x = new SharedWorker(worker.js, my worker);| returns a worker with the same scope. This does somewhat expose the GC-like shared worker lifetime. But not more than the SharedWorker constructor already does. / Jonas
Re: File URN lifetimes and SharedWorkers
On Tue, 23 Feb 2010, Drew Wilson wrote: This was recently brought to my attention by one of the web app developers in my office: http://dev.w3.org/2006/webapi/FileAPI/#lifeTime User agents MUST ensure that the lifetime of File URN #dfn-fileURNs is the same as the lifetime of the Document [HTML5 #HTML5] of the origin script which spawned the File #dfn-file object on which the urn #dfn-urn attribute was called. When this Document is destroyed, implementations MUST treat requests for File URN #dfn-fileURNs created within thisDocument as 404 Not Found.[Processing Model #processing-model-urn for File URN #dfn-fileURN s] I'm curious how this should work for SharedWorkers - let's imagine that I create a File object in a document and send it to a SharedWorker via postMessage() - the SharedWorker will receive a structured clone of that File object, which it can then access. What should the lifetime of the resulting URN for that file object be? I suspect the intent is that File objects ought to be tied to an owning script context rather than to a specific Document (so, in this case, the lifetime of the resulting URN would be the lifetime of the worker)? Was this ever addressed? Do I need to add something to the workers spec for this? Who is currently editing the File API specs? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
