W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

File URN lifetimes and SharedWorkers

From: Drew Wilson <atwilson@google.com>
Date: Tue, 23 Feb 2010 14:03:16 -0800
Message-ID: <f965ae411002231403h67b4de8je1e603e57b5ebc16@mail.gmail.com>
To: WebApps WG <public-webapps@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:37 GMT