W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2010

Re: New filesystem/directory API proposal

From: イアンフェッティ <ifette@google.com>
Date: Mon, 1 Feb 2010 12:49:28 -0800
Message-ID: <bbeaa26f1002011249x62d393deleeaa9e4ee895c658@mail.gmail.com>
To: Michael Nordman <michaeln@google.com>
Cc: Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, Arve Bersvendsen <arveb@opera.com>, public-device-apis@w3.org
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/
Received on Monday, 1 February 2010 20:50:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:17 UTC