Re: File API and Directory API feedback

On Thu, Feb 10, 2011 at 4:55 PM, Eric Uhrhane <ericu@google.com> wrote:
> 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.

Having heard no other comments on this, I've changed the name to toURL
and changed resolveLocalFileSystemURI to resolveLocalFileSystemURL, to
be more consistent with the rest of the platform.

> 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 Wednesday, 16 March 2011 23:35:40 UTC