On Tue, Sep 3, 2013 at 5:54 PM, Glenn Maynard <gl...@zewt.org> wrote: > On Tue, Sep 3, 2013 at 11:31 AM, Arun Ranganathan <a...@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.
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. > On Tue, Sep 3, 2013 at 11:28 AM, Anne van Kesteren <ann...@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... Well, my suggestion was rawName and name (which would have loss of information), per the current zip archive API design. > 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. -- http://annevankesteren.nl/
