W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2010

Re: New filesystem/directory API proposal

From: Anne van Kesteren <annevk@opera.com>
Date: Sat, 30 Jan 2010 14:28:28 +0100
To: ifette@google.com
Cc: "Eric Uhrhane" <ericu@google.com>, "Arve Bersvendsen" <arveb@opera.com>, public-device-apis@w3.org
Message-ID: <op.u7ck1qsk64w2qv@annevk-t60>
On Sat, 30 Jan 2010 14:21:34 +0100, Ian Fette (イアンフェッティ)  
<ifette@google.com> wrote:
> What you propose seems like a ton of added complexity in the browser,  
> and I don't get why it is necessary. Adding another level of indirection  
> would
> slow things down, and generally give people enough rope to hang  
> themselves on corner cases when the actual use cases for this are  
> extremely small. Is there actually any use case for creating a filename  
> that doesn't conform to the restrictions proposed? (I'm assuming that if  
> such a file already exists on disk, you will be able to access it  
> somehow, either by the user selecting it with <input type=file> or by  
> the DeviceFS?)
>
> I really dislike the idea of the filesystem being opaque to the user. If
> someone is on a device that has a filesystem browser (e.g. a desktop
> computer), they should be able to browse to see what the heck webapps are
> storing on their computer, without having to consult some database for  
> name translations. Similarly, if I want iTunes to be able to index my
> lala.com"filesystem", I want it to have access to the actual names.
>
> My $0.02

Yeah you're right, slow morning o_O. Taking the union of restrictions of  
all common file systems today for writing should suffice. Future file  
systems will be designed with compatibility for these APIs in mind in any  
case (one would hope).


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Saturday, 30 January 2010 13:29:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:41 UTC