Re: File API Feedback

On Fri, 19 Jun 2009, Jonas Sicking wrote:
> 
> The problems that seems like they need to be solved are security (are 
> these URIs accessible by any domain), and lifetime (how long does the 
> URI work).

The security would be that the origin of these URLs is fixed to be the 
origin of the script context (the "first script" in HTML5 terms) that 
invoked the method that minted the URL.

The lifetime... the easiest lifetime is the same lifetime as the Document 
of the script that was used to get the origin. This can lead to these URLs 
floating around after they have died, though; e.g. you could take an 
<img>, pass it to a script in another doc, and have the Document totally 
be GC'ed while the other <img> element still exists, and then the URL 
suddenly fails if it is used in another <img>.

The most conservative lifetime would be the lifetime of the browser, but 
that may be overly long.

Maybe we should have an API that, given one of these URLs, can return a 
File object (e.g. maybe the File object has a constructor that takes a URL 
and then that File can be used to refer to that URL, which might actually 
be useful in general); if we have that, then anyone who wants the URL to 
be usable beyond the original lifetime of the Document but that doesn't 
have access to the original File can just spawn a new one.

So my proposal would be to make the lifetime that of the creating script's 
Document.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 19 June 2009 23:06:03 UTC