- From: Eric Uhrhane <ericu@google.com>
- Date: Mon, 1 Feb 2010 20:11:11 -0800
- 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