- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 23 Jul 2010 07:15:50 +0000 (UTC)
- To: WebApps WG <public-webapps@w3.org>
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-fileURN>s 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-fileURN>s 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. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 23 July 2010 07:16:19 UTC