File API and Directory API feedback

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.

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


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

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

* What is the use case for FileSystem.name?

* 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?

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

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

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

* 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?

Is there somewhere that such issues should be filed?

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

Received on Thursday, 10 February 2011 23:28:06 UTC