- From: Drew Wilson <atwilson@google.com>
- Date: Tue, 23 Feb 2010 14:03:16 -0800
- To: WebApps WG <public-webapps@w3.org>
- Message-ID: <f965ae411002231403h67b4de8je1e603e57b5ebc16@mail.gmail.com>
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)? -atw
Received on Tuesday, 23 February 2010 22:03:47 UTC