Re: File API: File's name property

On Tue, Sep 3, 2013 at 11:31 AM, Arun Ranganathan <arun@mozilla.com> wrote:

> And, restrict separators such as "/" and "\".
>

I thought we just agreed that "\" is a platform-specific thing that
File.name shouldn't restrict.  "/" is a directory separator on just about
every platform, but "\" can appear in filenames on many systems.

On Tue, Sep 3, 2013 at 11:28 AM, Anne van Kesteren <annevk@annevk.nl>wrote:

> ByteString doesn't work. A byte sequence might. If the platform does
> file names in Unicode it would be converted to bytes using utf-8.
>

I don't know what API is being suggested that would keep File.name acting
like a String, but also allow containing arbitrary bytes.  I could imagine
one (an object that holds bytes, stringifies assuming UTF-8 and converts
from strings assuming UTF-8), but that's pretty ugly...

On Tue, Sep 3, 2013 at 11:42 AM, Anne van Kesteren <annevk@annevk.nl>wrote:

> That doesn't solve the problem I mentioned earlier for arbitrary file
> names coming out of zip archives. And then your data model is not
> bytes, but Unicode scalar values. We could of course accept
> information loss of some kind in the conversion process between zip
> archive resources and File objects and require developers to keep
> track of that if they care.
>

If you want to retain the original bytes of the filename somewhere, it
seems like it should go somewhere other than File.name.  For example, a
subclass of File, ZipFile, could contain a ByteString filenameBytes with
the original filename.  I wonder when you'd need that info, though.

By the way, in the current ZIP URL proposal, where would a File be
created?  If you use XHR to access a file inside a ZIP URL then you'd just
get a Blob, right?

-- 
Glenn Maynard