Re: New filesystem/directory API proposal

On Wed, Feb 3, 2010 at 11:36 PM, Anselm R Garbe <garbeam@gmail.com> wrote:
> 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.

I think you leave the realm of "corner cases" when you're talking
about the behavior of the majority of systems on which the code can be
expected to run.  And by adding these [fairly minor, IMO] restrictions
on filenames, your app developers don't have to write
platform-specific code at all--they just write to the web platform.
Isn't that simpler than making developers who want to write robust
code deal with multiple behaviors?  We keep the platform-specific code
in a dozen web browser implementations, so that millions of web apps
don't have to worry about it.

I agree that pulling specific restrictions out of decades-old
filesystems and enshrining them in the spec is inelegant.  The fact
remains that that's the environment in which we have to design.  Let's
see what we can do to improve the situation, not just pass the buck.

>> 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.

+1.

Received on Thursday, 4 February 2010 18:25:03 UTC