Re: File API: File's name property

On Tue, Sep 3, 2013 at 5:54 PM, Glenn Maynard <glenn@zewt.org> wrote:
> 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.

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

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/

Received on Tuesday, 3 September 2013 17:04:48 UTC