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
>