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

I've grouped responses to bits of this thread so far below:

Glenn said:
> 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.

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.

I also don't think having code that works in one locale and not another
[Glenn's "image.jpg" example] is fantastic.  It was what we were stuck with when
I was trying to allow implementers the choice of a pass-through implementation,
but given that that's fallen to the realities of path lengths on Windows, I feel
like we should try to do better.

Glenn:
> This can be solved at the application layer in applications that want
> it, without baking it into the filesystem API.

This is mostly true; you'd have to make sure that all alterations to the
filesystem went through a single choke-point or you'd have the potential for
race conditions [or you'd need to store the original-case filenames yourself,
and send the folded case down to the filesystem API].

Glenn:
> A virtual FS as the backing for the filesystem API does not resolve that core
> issue.  It makes sense to encourage authors to gracefully handle errors thrown
> by  creating files and directories.  Such a need has already been introduced
> via Google Chrome's unfortunate limitation of a 255 byte max path length.

That limitation grew out of the OS-dependent passthrough implementation.  We're
fixing that right now, with this proposal.

> The one take-away I have from that bug: it would have been nice to have a more
> descriptive error message.  It took awhile to figure out that the path length
> was too long for the implementation.

I apologize for that--it was an oversight.  If we can relax the restrictions to
a small set, it'll be more obvious what the problems are.  IIRC this problem was
particularly confusing because we were stopping you well short of the allowed
255 bytes, due to the your profile's nesting depth.

I'd like to obviate the need for complicated exceptions or APIs that suggest
better names, by leaving naming up to the app developer as much as possible.

[segue into other topics]

Glenn asked about future expansions of IndexedDB to handle Blobs, specifically
with respect to FileWriter and efficient incremental writes.

Jonas replied:
> A combination of FileWriter and IndexedDB should be able to handle
> this without problem. This would go beyond what is currently in the
> IndexedDB spec, but it's this part that we're planning on
> experimenting with.
>
> The way I have envisioned it to work is to add a function called
> createFileEntry somewhere, for example the IDBFactory interface. This
> would return a fileEntry which you could then write to using
> FileWriter as well as store in the database using normal database
> operations.

As Jonas and I have discussed in the past, I think that storing Blobs via
reference in IDB works fine, but when you make them modifiable FileEntries
instead, you either have to give up IDB's transactional nature or you have to
give up efficiency.  For large mutable Blobs, I don't think there's going to be
a clean interface there.  Still, I look forward to seeing what you come up with.

	Eric

Received on Wednesday, 11 May 2011 23:09:37 UTC