- From: Anselm R Garbe <garbeam@gmail.com>
- Date: Thu, 4 Feb 2010 07:36:47 +0000
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Arve Bersvendsen <arveb@opera.com>, Eric Uhrhane <ericu@google.com>, public-device-apis@w3.org
On 3 February 2010 18:40, Jeremy Orlow <jorlow@chromium.org> wrote: > On Wed, Feb 3, 2010 at 4:08 AM, Anselm R Garbe <garbeam@gmail.com> wrote: >> Speaking as an individual, I'd avoid to find a suitable cross-platform >> solution for these file name limitations. Imho it should be up to the >> API implementation on a specific platform to support/fail in such >> corner cases. On a Windows platform you'd simply have >> case-insensitiveness, on a Unix/Linux platform you'd have >> case-sensitiveness and support for all UTF-8 characters. Simple as >> that. > > You'd then be putting the burden on the sites using the APIs and not the > UAs. I think most of us can agree that's a bad thing. Well, the problem I see is imposing fundamental design decisions caused by corner cases (file name limitations on certain platforms). Imho the most portable designs I came across so far where those that do not attempt any platform-specific treatments. > Having a 1:1 correspondence between on disk file names and virtual file > names without resorting to a lookup table should be a requirement for our > solution, I think. Having implementations escape characters that won't work > on their platform + a very small number of reserved characters (though isn't > strictly necessary) seems like the way to go. Because there'll always be > some platform/file-system in the future with other weird rules/conventions. > Which I believe is what Hixie is also advocating for. The territory to deal with such mappings is full of pitfalls, as I said earlier, I wouldn't do that for simplicity reasons. Less is more. Cheers, Anselm
Received on Thursday, 4 February 2010 07:37:20 UTC