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

Re: New filesystem/directory API proposal

From: Eric Uhrhane <ericu@google.com>
Date: Mon, 1 Feb 2010 20:11:11 -0800
Message-ID: <44b058fe1002012011q29381094l1fc503a92d9c7605@mail.gmail.com>
To: ifette@google.com
Cc: Michael Nordman <michaeln@google.com>, Anne van Kesteren <annevk@opera.com>, Arve Bersvendsen <arveb@opera.com>, public-device-apis@w3.org
2010/2/1 Ian Fette (イアンフェッティ) <ifette@google.com>:
> 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...

That would certainly be the easy way out; you could look up the
FIleEntry by enumerating the directory, and you'd never have to ask
for an entry by illegal path.

>> 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 Tuesday, 2 February 2010 04:12:02 UTC

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