Re: New filesystem/directory API proposal

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