Re: File API: File's name property

On Tue, Sep 3, 2013 at 12:04 PM, Anne van Kesteren <annevk@annevk.nl>wrote:

> The problem is that once you put it through the URL parser it'll
> become "/". And I suspect given directory APIs and such it'll go
> through that layer at some point.
>

I don't follow.  Backslashes in filenames are escaped in URLs (
http://zewt.org/~glenn/test%5Cfile), like all the other things that require
escaping.

 Well, my suggestion was rawName and name (which would have loss of
> information), per the current zip archive API design.
>

Having a separate field is fine.  This is specific to ZIPs, so it feels
like it belongs in a ZipFile subclass, not File itself.  We definitely
wouldn't want raw bytes from filenames being filled in from user
filesystems (eg. Shift-JIS filenames in Linux), and Windows filenames
aren't even bytes (they're natively UTF-16).


> > 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?
>
> There's an API too.
>

It might be better to wait until we have a filesystem API, then piggyback
on that...

-- 
Glenn Maynard