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: Thu, 12 May 2011 02:47:05 +0300
Message-ID: <BANLkTiknG6TddsSb7G=GiyUEUhOqN_+C1Q@mail.gmail.com>
To: Eric U <ericu@google.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Glenn Maynard <glenn@zewt.org>, Web Applications Working Group WG <public-webapps@w3.org>, Charles Pritchard <chuck@jumis.com>, Kinuko Yasuda <kinuko@google.com>
On Thu, May 12, 2011 at 2:08 AM, Eric U <ericu@google.com> wrote:
> Timeless replied:
>> 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.
>
> You're proposing not just a case-insensitive system, but one that forces e.g. an
> English locale on all users, even those in a Turkish locale.  I don't think
> that's an acceptable solution.

No, I proposed case preserving. If the file is first created with a
dotless i, that hint is preserved and a user agent could and should
retain this (e.g. for when it serializes to a real file system). I'm
just suggesting not allowing an application to ask for distinct dotted
and dotless instances of the same approximate file name. There's a
reasonable chance that case collisions will be disastrous when
serialized, thus it's better to prevent case collisions when an
application tries to create the file - the application can accept a
suggested filename or generate a new one.
Received on Wednesday, 11 May 2011 23:47:32 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT