W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: [File API: FileSystem] Path restrictions and case-sensitivity

From: timeless <timeless@gmail.com>
Date: Sun, 8 May 2011 22:50:00 +0300
Message-ID: <BANLkTinHqoVmj3iFvZGv2Rfw4DXy+m494A@mail.gmail.com>
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 Sun, May 8, 2011 at 5:44 AM, Glenn Maynard <glenn@zewt.org> wrote:
> If *this API's* concept of filenames is case-insensitive, then "IMAGE.JPG"
> and "image.jpg" represent the same file on English systems and two different
> files on Turkish systems, which is an interop problem.

no, if the api is case insensitive, then it's case insensitive
*everywhere*, both on Turkish and on English systems. Things could
only be case sensitive when serialized to a real file system outside
of the API. I'm not proposing a case insensitive system which is
locale aware, i'm proposing one which always folds.

> If you create "IMAGE.JPG" (dotless-I) in one part of your code and then
> refer to it elsewhere as "image.jpg" (dotted-i), it *does* work on an
> average (non-Turkish) system if filenames are case-insensitive.  Only when
> someone tries to use this same code on a Turkish system will it fail, where
> "I" and "i" are different characters.

No, the code would work on any conforming user agent. If someone were
to *serialize* to an actual file system outside of the useragent, then
things would be different, and again, that's where the serializer
would need to deal with it. And it would need to deal with it anyway
because not all paths will be valid or viable on the local file system
(file names may be too long or have reserved characters), so any html
(or similar content) would need to be modified by the serializer.
Received on Sunday, 8 May 2011 19:50:27 UTC

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