- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 10 Feb 2011 23:27:36 +0000 (UTC)
- To: public-webapps@w3.org
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