- 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
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