- From: イアンフェッティ <ifette@google.com>
- Date: Sat, 30 Jan 2010 05:21:34 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Eric Uhrhane <ericu@google.com>, Arve Bersvendsen <arveb@opera.com>, public-device-apis@w3.org
- Message-ID: <bbeaa26f1001300521q5d214357me5e3b97b965f70b3@mail.gmail.com>
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 2010/1/30 Anne van Kesteren <annevk@opera.com> > On Fri, 29 Jan 2010 23:46:58 +0100, Eric Uhrhane <ericu@google.com> wrote: > >> I disagree; I think that if we want web apps that work all over the >> place, we should do our best to restrict behavior that would get in >> the way. Let's make it very easy to write portable code. >> > > How about letting any DOMString be acceptable and let the UA keep a mapping > between where the file is actually located and the DOMString the author is > using? I.e. one simple level of abstraction in between to hide the > complexity from authors. > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > >
Received on Saturday, 30 January 2010 13:22:06 UTC