- From: timeless <timeless@gmail.com>
- Date: Sun, 8 May 2011 04:24:53 +0300
- To: Glenn Maynard <glenn@zewt.org>
- Cc: Eric U <ericu@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Charles Pritchard <chuck@jumis.com>, Kinuko Yasuda <kinuko@google.com>
On Fri, May 6, 2011 at 8:22 PM, Glenn Maynard <glenn@zewt.org> wrote: > This can be solved at the application layer in applications that want > it, without baking it into the filesystem API. I wasn't talking about baking it into the api, i meant that the application using it could write such code. > I don't know what you're talking about. We're not talking about > serializing to FAT, we're talking about case-sensitivity within > virtualized filenames. you raised an issue involving if something were serialized, and i noted that the serialized case is already unhappy with eric's proposal. > Again, if filenames are case-insensitive, then the API will work > differently on a Turkish system than other systems, as I described, in > a way that's guaranteed to cause interop failures. This point stands. someone generating the content is likely to generate the file name references directly too (as i noted), as such it's unlikely that problems will happen. case 1: file is '<dotless-i>', file reference is '<dotted-i>', the generated content does *not* work on your *average* system. someone notices relatively quickly. case 2: file is '<dotted-i>', file reference is '<dotless-i>', the generated content does *not* work on your *average* system. someone notices relatively quickly. case 3: file is '<dotted-i>', file reference is '<dotted-i>', the generated content should work everywhere. case 4: file is '<dotless-i>', file reference is '<dotless-i>', the generated content will work or not depending on the user agent's ability to safely serialize the content (file and referencing file) to the host platform. this case is no different than with any other rule set.
Received on Sunday, 8 May 2011 01:25:20 UTC