Re: New filesystem/directory API proposal

About file naming constraints and characteristics, perhaps the
"WebFileSystem" (the one(s) accessible to the browser world via the
WindowLocalFS interface) have the same characteristics regardless of
underlying platform. The characteristics that eric pitched seem reasonable.

But in the device API, there are other FileSystems that can be accessed via
the DeviceFS interface. I think those file systems could reflect the
characteristics of the underlying file system in their full glory w/o
interfering with web standards.

The .caseSensitive and .casePreserving attributes of the file system object
may be in use in this scheme.

Some questions...

What happens when the user tries to copy an invalidly named file into the
WebFS?

What happens when some external program generates an invalidly name file in
the directory being employed by the WebFS (assuming an impl is doing the
obvious thing and directly mapping a native directory to the root of the
WebFS)?


On Sat, Jan 30, 2010 at 5:28 AM, Anne van Kesteren <annevk@opera.com> wrote:

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