W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2010

Re: New filesystem/directory API proposal

From: Anselm R Garbe <garbeam@gmail.com>
Date: Thu, 4 Feb 2010 07:36:47 +0000
Message-ID: <89d1e7b81002032336h179a3868oc89121c7efff67a6@mail.gmail.com>
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.

Received on Thursday, 4 February 2010 07:37:20 UTC

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