Re: File URN lifetimes and SharedWorkers

On Fri, Jul 23, 2010 at 12:15 AM, Ian Hickson <ian@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-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?

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

Received on Monday, 26 July 2010 21:50:49 UTC