Re: File API and Directory API feedback
On Wed, Mar 16, 2011 at 4:59 PM, Charles Pritchard wrote: > On 3/16/2011 4:34 PM, Eric Uhrhane wrote: >> >> On Thu, Feb 10, 2011 at 4:55 PM, Eric Uhrhane wrote: >>> >>> On Thu, Feb 10, 2011 at 3:27 PM, Ian Hickson 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, 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. > > Seems like the qualities of the FileEntry interface. Returns a blob > interface async, which can then be read async. > canvas.toFileEntry().file( callback ) > > toFileEntry is synchronous, returning a generic fileentry object, > file method is async, and can return a typed array or blob. > > Was there discussion on using FileEntry semantics? Not that I recall. It's not a great match, really, because the data returned from a Canvas doesn't have a name, a parent directory, etc. If you just need an asynchronous way to get a File or Blob from a Canvas, just make Canvas.toFile take a callback.
Re: File API and Directory API feedback
On 3/16/2011 4:34 PM, Eric Uhrhane wrote: On Thu, Feb 10, 2011 at 4:55 PM, Eric Uhrhane wrote: On Thu, Feb 10, 2011 at 3:27 PM, Ian Hickson 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, 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. Seems like the qualities of the FileEntry interface. Returns a blob interface async, which can then be read async. canvas.toFileEntry().file( callback ) toFileEntry is synchronous, returning a generic fileentry object, file method is async, and can return a typed array or blob. Was there discussion on using FileEntry semantics?
Re: File API and Directory API feedback
On Thu, Feb 10, 2011 at 4:55 PM, Eric Uhrhane wrote:
> On Thu, Feb 10, 2011 at 3:27 PM, Ian Hickson 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 , 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.
Re: File API and Directory API feedback
Eric Uhrhane , 2011-02-11 15:10 -0800: > Michael, thanks. However, I chose to use the tracker originally since > that's what the File API was using. I'd rather not have 2 different > places to log issues. If there's a strong reason I should move to > Bugzilla, let me know, but otherwise I think we should remove those > components. The reason is that only members of the group can raise issues in the tracker. So bugzilla is useful if you want to enable public commenters to raise issues. --Mike -- Michael[tm] Smith http://people.w3.org/mike
Re: File API and Directory API feedback
On Fri, Feb 11, 2011 at 4:33 AM, Michael[tm] Smith wrote: > Eric Uhrhane , 2011-02-10 16:55 -0800: > >> On Thu, Feb 10, 2011 at 3:27 PM, Ian Hickson wrote: >> > 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. > > If you care to use bugzilla, I've created components for FileWriter and > FileSystem in the WebApps product in the W3C bugzilla: > > http://www.w3.org/Bugs/Public/describecomponents.cgi?product=WebAppsWG Michael, thanks. However, I chose to use the tracker originally since that's what the File API was using. I'd rather not have 2 different places to log issues. If there's a strong reason I should move to Bugzilla, let me know, but otherwise I think we should remove those components. > Eric, if you create a W3C bugzilla account (and give me a heads-up after), > I'll set you as the default assignee for those components. > > --Mike > > -- > Michael[tm] Smith > http://people.w3.org/mike >
Re: File API and Directory API feedback
Eric Uhrhane , 2011-02-10 16:55 -0800: > On Thu, Feb 10, 2011 at 3:27 PM, Ian Hickson wrote: > > 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. If you care to use bugzilla, I've created components for FileWriter and FileSystem in the WebApps product in the W3C bugzilla: http://www.w3.org/Bugs/Public/describecomponents.cgi?product=WebAppsWG Eric, if you create a W3C bugzilla account (and give me a heads-up after), I'll set you as the default assignee for those components. --Mike -- Michael[tm] Smith http://people.w3.org/mike
Re: File API and Directory API feedback
On Thu, Feb 10, 2011 at 6:27 PM, Ian Hickson wrote: > * Is Blob.size supposed to be synchronous? I'm looking into adding a way > to get a Blob from , 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. > You need to know the size of a Blob for the Blob's own synchronous API to work. In particular, Blob.slice needs to know the blob's size to clamp its parameters. -- Glenn Maynard
Re: File API and Directory API feedback
On Thu, Feb 10, 2011 at 3:27 PM, Ian Hickson 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 , 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.
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 happen
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 , 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. `._.-(,_..'--(,_..'`-.;.'
