W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [File API] data URL method

From: Arve Bersvendsen <arveb@opera.com>
Date: Thu, 02 Jul 2009 21:06:22 +0200
To: "Jonas Sicking" <jonas@sicking.cc>, "Anne van Kesteren" <annevk@opera.com>
Cc: "WebApps WG" <public-webapps@w3.org>
Message-ID: <op.uwgfcrp5byn2jm@galactica>
On Thu, 02 Jul 2009 18:38:03 +0200, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Jul 2, 2009 at 2:58 AM, Anne van Kesteren<annevk@opera.com>  
> wrote:
>> I tend to think that if we are going to introduce a URL scheme to point  
>> to file data on the system we should not be adding the data URL method.  
>> As far as I can tell there are no benefits to introducing it as it will  
>> only increase memory usage when used by authors and the uses it has can  
>> be perfectly achieved using the local file URL. Also, the local URL can  
>> be a synchronous API as there is no need to read the entire file  
>> directly and store it all into memory. You only need to return a URL.
>> I.e. instead of
>>  file.getAsDataURI(
>>    function(dataURL) { img.src = dataURL }
>>  )
>> you would get
>>  img.src = file.localURL
>> which is better in many ways and not worse in any way I can think of  
>> (maybe apart from moving the discussion with the TAG regarding a new  
>> URL scheme a little bit ahead).
> This would be a more interesting discussion if someone could actually
> come up with a spec for localURL :)

Opera's File IO implementation for Widgets and Unite services (Which I  
would very much prefer to see unified with this spec, since there is a lot  
of overlap) has a concept of "local" URLs which is roughly as follows:


Where the path is the relative path from the file object corresponding to  
the mountpoint name. The original path is not exposed.

Note that even when selecting just a file, actually having a path  
reference is useful, if you at some point want to treat common archive  
formats as directories you want to descend in to, for the purpose of  
opening resources in for instance ODF or epub format documents.

> Mostly it's the lifetime issue that concerns me. How long is such a
> URL expected to work, and how do we prevent people from using it
> longer than that?

Our initial security context is a bit different from in file upload, but  
the lifetime is one of the following:

1. Until unmounted manually, this is probably not a good idea for a file  
upload context.
2. Until the document is either destroyed or reloaded.  In the context of  
file upload, I would assume "until the user navigates away from the  
document would be sufficient.

Arve Bersvendsen

Opera Software ASA, http://www.opera.com/
Received on Thursday, 2 July 2009 19:07:16 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:17 UTC