Re: New filesystem/directory API proposal

2010/2/1 Michael Nordman <michaeln@google.com>

> 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.
>
>
This still seems sad, as then you will be writing non-portable code.


> 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)?
>
>
I would presume that it could still be opened, and that these validation
checks would occur when a file is being created / renamed...


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