- From: Eric U <ericu@google.com>
- Date: Tue, 3 May 2011 17:58:30 -0700
- To: Web Applications Working Group WG <public-webapps@w3.org>
- Cc: Charles Pritchard <chuck@jumis.com>, Glenn Maynard <glenn@zewt.org>, Kinuko Yasuda <kinuko@google.com>
I'd like to bring back up the discussion that went on at [1] and [2]. In particular, I'd like to propose a minimal set of restrictions for file names and paths, punt on the issue of what happens in later layers of the API, and discuss case-sensitivity rules. For the sandboxed filesystem, I propose that we disallow only: * Embedded null characters [will likely break something somewhere] * Embedded forward slash (/) [it's our delimiter] * Embedded backslash (\) [will likely confuse people if we permit it] * Files called '.' [has a meaning for us already] * Files called '..' [has a meaning for us already] * Path segments longer than 1KB [probably long enough, and I feel better having a limit] ...and explicitly support anything other than that. I'm not proposing a maximum path length at this time...perhaps we should just say "MUST support at least X" for some large X? Regarding case sensitivity: I originally specced it as case-insensitive-case-preserving to make it easier to support a passthrough implementation on Windows and Mac. However, as passthroughs have turned out to be unfeasible [see previous thread on path length problems], all case insensitivity really gets us is potential locale issues. I suggest we drop it and just go with a case-sensitive filesystem. Eric [1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1031.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0704.html
Received on Wednesday, 4 May 2011 00:59:13 UTC