- From: Eric Uhrhane <ericu@google.com>
- Date: Wed, 16 Mar 2011 16:34:54 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-webapps@w3.org
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