Re: File API and Directory API feedback

On Thu, Feb 10, 2011 at 3:27 PM, Ian Hickson <ian@hixie.ch> wrote:
>
> A couple of points I noticed while briefly perusing the File API specs:
>
> * Blob.size has no conformance criteria (no "must"s). It could return a
> random number each time and that would be conforming. It seems like it
> should have at least some constraint related to how a FileReader
> interacts with the Blob.
>
> * Is Blob.size supposed to be synchronous? I'm looking into adding a way
> to get a Blob from <canvas>, but trying to avoid the mistake I made with
> toDataURL of having the data be synchronously available. That's fine with
> Blob and FileReader, the data can be read async, but the browser won't
> know the size of the file ahead of time, which means that I guess I should
> have a callback to get the Blob? It seems sad that we need to be async
> both in getting the Blob _and_ in getting the data from the Blob.

Yes, Blob.size is synchronous.  This came up the last time people
discussed getting one from a canvas, and nobody had a good solution
that I can recall.

> * Why are createObjectURL() and revokeObjectURL() on the URL interface
> object rather than on Window or Navigator? This is highly unusual (it's
> the first case I can think of outside JS where we have done this).

This came out of discussions at TPAC in Lyon; some people didn't want
it cluttering up the Window namespace.

> * FileSystem is quite heavy-weight when all you want is a file.
> Discounting error handling, getting a file stored as "/file" in a
> filesytem requires the following code:
>
>   window.requestFileSystem(1, 0, function (fs) {
>     fs.root.getFile('/file', {}, function (fe) {
>       fe.file(function (f) {
>         processFile(f);
>       })
>     });
>   });
>
> Two proposals to help reduce the confusion this causes:
>
>  - I think we should rename 'getFile' to 'getFileEntry' since 'File' is
>   something different than what 'getFile' provides.

I'm open to that if folks want it.  It seems reasonable.

>  - We should consider adding a getFile() method on FileSystem, and maybe
>   even on DirectoryEntry, which gives you a File directly. That would
>   allow the above to be rewritten as:
>
>   window.requestFileSystem(1, 0, function (fs) {
>     fs.getFile('/file', function (f) {
>       processFile(f);
>     });
>   });
>
> ...which is at least a little improvement.

If we were going to put it anywhere, DirectoryEntry makes more sense
than FileSystem, I think.  [fs->fs.root in the above example]

> * What is the use case for FileSystem.name?

It's just a human-readable identifier that might be useful for
debugging AFAIK.  I'd have no objection to dropping it, actually.

> * What is FileEntry.toURI? If we have it at all, it should at least be
> called toURL to be consistent with the rest of the platform, but do we
> need it? Is it redundant with createObjectURL()? What are the cross-origin
> implications of such a URL getting leaked to another origin?

Regarding createObjectURL--the URLs it creates for Blobs are tied to
the lifetime of the page, and are generally undecipherable Blob URNs.
The URLs returned by toURI are persistent, and the intent is that
they'll be human-readable and -editable, and contain the obvious path
information.  We can certainly change the name to toURL if that fits
better.

There's some discussion at [1] regarding cross-origin use and the URI format.

Regarding cross-origin leaks, we still haven't settled whether the
URLs can be used cross-origin or not.  We may just not want to make
that work at all, given that there's no way to provide access controls
once a URL leaks.

> * In the FileSystem API spec, "Error Code Descriptions" and "The
> FileException exception" seem to disagree on codes.

I see that when I updated most references to the new values, I missed
the table in 7.3.  Thanks for catching that.  Fixed.

> * The subsections of "Dealing with errors and exceptions" give the error
> codes in a different order each time.

I see the definitions of FileException and FileError using the same
numeric order on the constants, and I see the constants declared in
7.1.2 and 7.2.2 in alphabetical order.  Is that what you see?  Is the
only problem that 7.3's order doesn't match 7.2.2?  I'll fix that.

> * None of the methods really describe what they do. For example,
> createWriter is defined as "Creates a new FileWriter associated with the
> file that this FileEntry represents". There are no conformance
> requirements there. Nothing says when the successCallback is called or
> when the errorCallback is called. Nothing says what the parameters to
> those callbacks are. etc.

I'll flesh that out.  However, the callback parameters are defined in
the callback definitions [e.g. 5.6.5].  I can certainly add some
explanations, though.

> * Some of the conformance requirements are very unclear about what they
> mean. For example, "File and directory names must not end in period or
> space": is that a requirement on authors or implementations? What happens
> if they do?

I'll clarify that.  It's a requirement on paths supplied to the API,
and paths that violate these rules must be rejected by the
implementation.

> Is there somewhere that such issues should be filed?

I'm not sure about the File API--it used to use [2], but I'm not sure
if it still does.
I've got [3] for FileWriter and [4] for FileSystem.  I'd appreciate
any issues you'd care to log.


> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0218.html
[2] http://www.w3.org/2008/webapps/track/products/11
[3] http://www.w3.org/2008/webapps/track/products/23
[4] http://www.w3.org/2008/webapps/track/products/24

Received on Friday, 11 February 2011 00:55:56 UTC