Re: New FileAPI Draft | was Re: FileAPI feedback
On Mon, Aug 17, 2009 at 6:01 PM, Arun Ranganathana...@mozilla.com wrote: Nikunj R. Mehta wrote: On Aug 5, 2009, at 6:55 PM, Jonas Sicking wrote: What's the use-case for getAsBase64? I have another use case for this. The Atom Publishing protocol per RFC 5023 [1] accepts inline binary data represented in base 64 encoding. In order to submit binary inline content in an Atom entry to an Atom server, it would be necessary to getAsBase64() Specifically, atom:entry can contain Base64-encoded content [2]; I'm not sure it allows *other ways* to submit inline binary content. I suppose one reason to keep the ability to get data in Base64 is for legacy reasons, since it happens to be a convenient way to get binary stuff into web content (and ultimately onto servers). The problem is that it is not as useful within webapps (at least, not as useful as binary content). Use cases submitted till now involve *submitting* binary content in Base64 to servers that can handle Base64, but not doing anything useful with Base64 *within* the web app (where I suspect the first thing someone might do is to convert it to a binary string again). I suppose one reason to keep it around is if: 1. Web app asks user to pick file 2. File is picked and extracted as Base64 3. Atom container with Base64 is submitted via XHR using the Atom Publishing Protocol [1]. I'm willing to keep a way to get data as Base64 around for such cases. There's lots of formats used on the web, I don't think it makes sense to add file-getters for all of them. JSON has gotten a lot of attention lately, does this mean we should add a getter that return a js-style escaped string? We have getAsBinaryString, using that you can get the raw data and then base64 or escape encode it, or convert it to whatever format you want. / Jonas
Re: New FileAPI Draft | was Re: FileAPI feedback
On Aug 17, 2009, at 11:08 PM, Jonas Sicking wrote: On Mon, Aug 17, 2009 at 6:01 PM, Arun Ranganathana...@mozilla.com wrote: Nikunj R. Mehta wrote: On Aug 5, 2009, at 6:55 PM, Jonas Sicking wrote: What's the use-case for getAsBase64? I have another use case for this. The Atom Publishing protocol per RFC 5023 [1] accepts inline binary data represented in base 64 encoding. In order to submit binary inline content in an Atom entry to an Atom server, it would be necessary to getAsBase64() Specifically, atom:entry can contain Base64-encoded content [2]; I'm not sure it allows *other ways* to submit inline binary content. I suppose one reason to keep the ability to get data in Base64 is for legacy reasons, since it happens to be a convenient way to get binary stuff into web content (and ultimately onto servers). The problem is that it is not as useful within webapps (at least, not as useful as binary content). Use cases submitted till now involve *submitting* binary content in Base64 to servers that can handle Base64, but not doing anything useful with Base64 *within* the web app (where I suspect the first thing someone might do is to convert it to a binary string again). I suppose one reason to keep it around is if: 1. Web app asks user to pick file 2. File is picked and extracted as Base64 3. Atom container with Base64 is submitted via XHR using the Atom Publishing Protocol [1]. I'm willing to keep a way to get data as Base64 around for such cases. There's lots of formats used on the web, I don't think it makes sense to add file-getters for all of them. JSON has gotten a lot of attention lately, does this mean we should add a getter that return a js-style escaped string? We have getAsBinaryString, using that you can get the raw data and then base64 or escape encode it, or convert it to whatever format you want. / Jonas An IETF working group has published standards track proposals for a format and a protocol that uses base 64 encoding. If this is not sufficient reason, then I am sorry but you have an unduly high expectation. Let the 'js-style escaped string' get a similar blessing and then they can bring it to W3C to include them in browsers. Nikunj http://o-micron.blogspot.com
Re: New FileAPI Draft | was Re: FileAPI feedback
On Mon, Aug 17, 2009 at 11:13 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: On Aug 17, 2009, at 11:08 PM, Jonas Sicking wrote: On Mon, Aug 17, 2009 at 6:01 PM, Arun Ranganathana...@mozilla.com wrote: Nikunj R. Mehta wrote: On Aug 5, 2009, at 6:55 PM, Jonas Sicking wrote: What's the use-case for getAsBase64? I have another use case for this. The Atom Publishing protocol per RFC 5023 [1] accepts inline binary data represented in base 64 encoding. In order to submit binary inline content in an Atom entry to an Atom server, it would be necessary to getAsBase64() Specifically, atom:entry can contain Base64-encoded content [2]; I'm not sure it allows *other ways* to submit inline binary content. I suppose one reason to keep the ability to get data in Base64 is for legacy reasons, since it happens to be a convenient way to get binary stuff into web content (and ultimately onto servers). The problem is that it is not as useful within webapps (at least, not as useful as binary content). Use cases submitted till now involve *submitting* binary content in Base64 to servers that can handle Base64, but not doing anything useful with Base64 *within* the web app (where I suspect the first thing someone might do is to convert it to a binary string again). I suppose one reason to keep it around is if: 1. Web app asks user to pick file 2. File is picked and extracted as Base64 3. Atom container with Base64 is submitted via XHR using the Atom Publishing Protocol [1]. I'm willing to keep a way to get data as Base64 around for such cases. There's lots of formats used on the web, I don't think it makes sense to add file-getters for all of them. JSON has gotten a lot of attention lately, does this mean we should add a getter that return a js-style escaped string? We have getAsBinaryString, using that you can get the raw data and then base64 or escape encode it, or convert it to whatever format you want. / Jonas An IETF working group has published standards track proposals for a format and a protocol that uses base 64 encoding. If this is not sufficient reason, then I am sorry but you have an unduly high expectation. Let the 'js-style escaped string' get a similar blessing and then they can bring it to W3C to include them in browsers. Note that base64 is still supported, I just don't think adding a convenience function on the File API is warranted. If we did, shouldn't we also add a base64 encoding function on XMLHttpRequest? the SQL (or other database) API? On postMessage? And then multiply that by the number of IETF blessed encodings? That adds up to a lot of API. If base64 is important enough that we should have built-in support for it, it seems better to support that separated from the File API so that it can be used with other data sources than files. / Jonas
Re: New FileAPI Draft | was Re: FileAPI feedback
Jonas Sicking wrote: There's lots of formats used on the web, I don't think it makes sense to add file-getters for all of them. JSON has gotten a lot of attention lately, does this mean we should add a getter that return a js-style escaped string? I don't really feel very strongly about keeping something equivalent to getAsBase64 (whatever the eventual model), but I don't think js-style escaped strings are an apples-to-apples comparison to Base64 encoded strings for binary content (but I suppose Atom and JSON bear comparison). We have getAsBinaryString, using that you can get the raw data and then base64 or escape encode it, or convert it to whatever format you want. This is true, but not as convenient to programmers. I think you feel that Base64 is one convenience too many, and starts a slippery slope :-) An IETF working group has published standards track proposals for a format and a protocol that uses base 64 encoding. If this is not sufficient reason, then I am sorry but you have an unduly high expectation. Let the 'js-style escaped string' get a similar blessing and then they can bring it to W3C to include them in browsers. shouldn't we also add a base64 encoding function on XMLHttpRequest? the SQL (or other database) API? On postMessage? Not necessarily (if we consider AtomPub uses cases). But again, I *do* agree that getAsBinaryString is the bare minimum convenience. I think getting stuff as Base64 is useful syntactic sugar, but can live without it. Do the purveyors of public-facing APIs that use or extend AtomPub have strong opinons? -- A*
Re: New FileAPI Draft | was Re: FileAPI feedback
On Tue, Aug 18, 2009 at 10:34 AM, Nikunj R.
Mehtanikunj.me...@oracle.com wrote:
On Aug 17, 2009, at 11:29 PM, Jonas Sicking wrote:
On Mon, Aug 17, 2009 at 11:13 PM, Nikunj R.
Mehtanikunj.me...@oracle.com wrote:
On Aug 17, 2009, at 11:08 PM, Jonas Sicking wrote:
On Mon, Aug 17, 2009 at 6:01 PM, Arun Ranganathana...@mozilla.com
wrote:
Nikunj R. Mehta wrote:
On Aug 5, 2009, at 6:55 PM, Jonas Sicking wrote:
What's the use-case for getAsBase64?
I have another use case for this. The Atom Publishing protocol per RFC
5023 [1] accepts inline binary data represented in base 64 encoding.
In
order to submit binary inline content in an Atom entry to an Atom
server, it
would be necessary to getAsBase64()
Specifically, atom:entry can contain Base64-encoded content [2]; I'm
not
sure it allows *other ways* to submit inline binary content. I suppose
one
reason to keep the ability to get data in Base64 is for legacy reasons,
since it happens to be a convenient way to get binary stuff into web
content
(and ultimately onto servers). The problem is that it is not as useful
within webapps (at least, not as useful as binary content). Use cases
submitted till now involve *submitting* binary content in Base64 to
servers
that can handle Base64, but not doing anything useful with Base64
*within*
the web app (where I suspect the first thing someone might do is to
convert
it to a binary string again).
I suppose one reason to keep it around is if:
1. Web app asks user to pick file
2. File is picked and extracted as Base64
3. Atom container with Base64 is submitted via XHR using the Atom
Publishing Protocol [1].
I'm willing to keep a way to get data as Base64 around for such cases.
There's lots of formats used on the web, I don't think it makes sense
to add file-getters for all of them. JSON has gotten a lot of
attention lately, does this mean we should add a getter that return a
js-style escaped string?
We have getAsBinaryString, using that you can get the raw data and
then base64 or escape encode it, or convert it to whatever format you
want.
/ Jonas
An IETF working group has published standards track proposals for a
format
and a protocol that uses base 64 encoding. If this is not sufficient
reason,
then I am sorry but you have an unduly high expectation. Let the
'js-style
escaped string' get a similar blessing and then they can bring it to W3C
to
include them in browsers.
Note that base64 is still supported, I just don't think adding a
convenience function on the File API is warranted.
I don't understand by what you mean that it is supported. Can you elaborate?
I mean that it's possible to use the current (minus getAsBase64) API
to send base64 encoded data to the server. You can do that in the
following way:
file.getAsBinaryString(handler);
function handler(binaryString, err) {
encodedString = base64Encode(binaryString);
xhr.open(POST, server.cgi);
xhr.send(encodedString);
}
function base64Encode(binaryString) {
... code from [1] ...
}
[1] http://www.webtoolkit.info/javascript-base64.html
So we don't need an explicit base64 getter on the file API in order to
allow data to be converted into base64.
If we did,
shouldn't we also add a base64 encoding function on XMLHttpRequest?
the SQL (or other database) API? On postMessage?
And then multiply that by the number of IETF blessed encodings? That
adds up to a lot of API.
If base64 is important enough that we should have built-in support for
it, it seems better to support that separated from the File API so
that it can be used with other data sources than files.
Perhaps you are suggesting that a file reader should support taking encoding
as an option so that the reader can obtain whatever format it is interested
in as long as the browser supports it. That would keep the API clean. If so,
I would suggest that base64 be a required encoding.
No, I'm suggesting that we decouple APIs that do encoding/decoding,
from APIs that deal with specific data sources. Otherwise we need to
add encoding/decoding APIs on each data source. So if we consider
base64 encoding to be critical, lets add a native API to implement the
base64Encode function in the example above.
/ Jonas
Re: New FileAPI Draft | was Re: FileAPI feedback
On Tue, Aug 18, 2009 at 11:25 AM, Arun Ranganathana...@mozilla.com wrote: Jonas Sicking wrote: There's lots of formats used on the web, I don't think it makes sense to add file-getters for all of them. JSON has gotten a lot of attention lately, does this mean we should add a getter that return a js-style escaped string? I don't really feel very strongly about keeping something equivalent to getAsBase64 (whatever the eventual model), but I don't think js-style escaped strings are an apples-to-apples comparison to Base64 encoded strings for binary content (but I suppose Atom and JSON bear comparison). We have getAsBinaryString, using that you can get the raw data and then base64 or escape encode it, or convert it to whatever format you want. This is true, but not as convenient to programmers. I think you feel that Base64 is one convenience too many, and starts a slippery slope :-) Yes. An IETF working group has published standards track proposals for a format and a protocol that uses base 64 encoding. If this is not sufficient reason, then I am sorry but you have an unduly high expectation. Let the 'js-style escaped string' get a similar blessing and then they can bring it to W3C to include them in browsers. shouldn't we also add a base64 encoding function on XMLHttpRequest? the SQL (or other database) API? On postMessage? Not necessarily (if we consider AtomPub uses cases). How so? Why would you only want to AtomPub-publish stuff that are read from files? Rather than read from other websites (think cross-site XHR), or stored in offline storage, or received through postMessage from another site? An AtomPub widget that you instantiate in an iframe and to to via postMessage sounds very plausible. But again, I *do* agree that getAsBinaryString is the bare minimum convenience. I think getting stuff as Base64 is useful syntactic sugar, but can live without it. Agreed. / Jonas
Re: New FileAPI Draft | was Re: FileAPI feedback
On Aug 18, 2009, at 11:50 AM, Jonas Sicking wrote:
On Tue, Aug 18, 2009 at 10:34 AM, Nikunj R.
Mehtanikunj.me...@oracle.com wrote:
On Aug 17, 2009, at 11:29 PM, Jonas Sicking wrote:
On Mon, Aug 17, 2009 at 11:13 PM, Nikunj R.
Mehtanikunj.me...@oracle.com wrote:
On Aug 17, 2009, at 11:08 PM, Jonas Sicking wrote:
On Mon, Aug 17, 2009 at 6:01 PM, Arun
Ranganathana...@mozilla.com
wrote:
Nikunj R. Mehta wrote:
On Aug 5, 2009, at 6:55 PM, Jonas Sicking wrote:
What's the use-case for getAsBase64?
I have another use case for this. The Atom Publishing protocol
per RFC
5023 [1] accepts inline binary data represented in base 64
encoding.
In
order to submit binary inline content in an Atom entry to an
Atom
server, it
would be necessary to getAsBase64()
Specifically, atom:entry can contain Base64-encoded content
[2]; I'm
not
sure it allows *other ways* to submit inline binary content. I
suppose
one
reason to keep the ability to get data in Base64 is for legacy
reasons,
since it happens to be a convenient way to get binary stuff
into web
content
(and ultimately onto servers). The problem is that it is not
as useful
within webapps (at least, not as useful as binary content).
Use cases
submitted till now involve *submitting* binary content in
Base64 to
servers
that can handle Base64, but not doing anything useful with Base64
*within*
the web app (where I suspect the first thing someone might do
is to
convert
it to a binary string again).
I suppose one reason to keep it around is if:
1. Web app asks user to pick file
2. File is picked and extracted as Base64
3. Atom container with Base64 is submitted via XHR using the
Atom
Publishing Protocol [1].
I'm willing to keep a way to get data as Base64 around for such
cases.
There's lots of formats used on the web, I don't think it makes
sense
to add file-getters for all of them. JSON has gotten a lot of
attention lately, does this mean we should add a getter that
return a
js-style escaped string?
We have getAsBinaryString, using that you can get the raw data and
then base64 or escape encode it, or convert it to whatever
format you
want.
/ Jonas
An IETF working group has published standards track proposals for a
format
and a protocol that uses base 64 encoding. If this is not
sufficient
reason,
then I am sorry but you have an unduly high expectation. Let the
'js-style
escaped string' get a similar blessing and then they can bring it
to W3C
to
include them in browsers.
Note that base64 is still supported, I just don't think adding a
convenience function on the File API is warranted.
I don't understand by what you mean that it is supported. Can you
elaborate?
I mean that it's possible to use the current (minus getAsBase64) API
to send base64 encoded data to the server. You can do that in the
following way:
file.getAsBinaryString(handler);
function handler(binaryString, err) {
encodedString = base64Encode(binaryString);
xhr.open(POST, server.cgi);
xhr.send(encodedString);
}
function base64Encode(binaryString) {
... code from [1] ...
}
[1] http://www.webtoolkit.info/javascript-base64.html
So we don't need an explicit base64 getter on the file API in order to
allow data to be converted into base64.
So it is possible to do encoding, except that it is not offered in the
API. Regardless, I feel that the use of binary strings and doing the
encoding in JavaScript is a bad approach and this spec should not move
programmers in that direction.
I think it is probably best to provide separate readers for each
different format - binary, encoded binary, and text. I feel that
Michael's proposal is better than the current editor's draft in that
it clearly separates the file from its readers and the data.
If we did,
shouldn't we also add a base64 encoding function on XMLHttpRequest?
the SQL (or other database) API? On postMessage?
And then multiply that by the number of IETF blessed encodings? That
adds up to a lot of API.
If base64 is important enough that we should have built-in support
for
it, it seems better to support that separated from the File API so
that it can be used with other data sources than files.
Perhaps you are suggesting that a file reader should support taking
encoding
as an option so that the reader can obtain whatever format it is
interested
in as long as the browser supports it. That would keep the API
clean. If so,
I would suggest that base64 be a required encoding.
No, I'm suggesting that we decouple APIs that do encoding/decoding,
from APIs that deal with specific data sources. Otherwise we need to
add encoding/decoding APIs on each data source. So if we consider
base64 encoding to be critical, lets add a native API to implement the
base64Encode function in the example above.
This I agree will be a step in the right direction. It seems you are
suggesting something similar to Java's InputStreamReader so that the
bytes can be
Re: New FileAPI Draft | was Re: FileAPI feedback
On Aug 12, 2009, at 7:29 AM, Arun Ranganathan wrote: Gregg Tavares wrote: How about this? Why make a new API for getting the contents of a file (local or otherwise) when we already have one which is XHR? What if FileList was just array of File objects where each File object is just a URL in the format filedata: uuid, filename Then you can use that URL anywhere in HTML a URL is valid. script, img, audio, video, css, AND XHR That would mean you wouldn't be adding a new API to get the contents of a file. If you want the contents just use XHR and use the URL from the File in the FileList. You could add a few more functions to XHR like request.getAsDataURL(), request.getAsTextInEncodiing(), etc. if need be if they are neede Today, it's possible to use XHR from privileged web content in Firefox to access file:// URLs; the drawback is that these don't return HTTP responses, and of course there are security considerations. As stated, the XHR algorithm for open() [1] allows relative references and resolves them relative to the document base URI. Does that mean that if the document was loaded using file: uri, then the XHR could be used for loading a file? As a separate question, it would be necessary for proper operation of XHR to always provide content-type and content-length headers when providing a response entity body. Does Firefox provide these headers when the XHR object is used to retrieve local file: representations? I'm not sure it is necessary to reuse the XHR primitive for general file access (though I find the idea of not distinguishing remote files from local pretty attractive), but I have defined the filedata: URL scheme to return some HTTP response codes [1], so that it can be used with XHR. What is permitted and what is not is bound to be a controversial discussion :-) -- A* [1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html Nikunj http://o-micron.blogspot.com [1] http://www.w3.org/TR/XMLHttpRequest/#xmlhttprequest
Re: New FileAPI Draft | was Re: FileAPI feedback
Nikunj R. Mehta wrote: On Aug 12, 2009, at 7:29 AM, Arun Ranganathan wrote: Gregg Tavares wrote: How about this? Why make a new API for getting the contents of a file (local or otherwise) when we already have one which is XHR? What if FileList was just array of File objects where each File object is just a URL in the format filedata: uuid, filename Then you can use that URL anywhere in HTML a URL is valid. script, img, audio, video, css, AND XHR That would mean you wouldn't be adding a new API to get the contents of a file. If you want the contents just use XHR and use the URL from the File in the FileList. You could add a few more functions to XHR like request.getAsDataURL(), request.getAsTextInEncodiing(), etc. if need be if they are neede Today, it's possible to use XHR from privileged web content in Firefox to access file:// URLs; the drawback is that these don't return HTTP responses, and of course there are security considerations. As stated, the XHR algorithm for open() [1] allows relative references and resolves them relative to the document base URI. Does that mean that if the document was loaded using file: uri, then the XHR could be used for loading a file? Currently, this behavior is not standard, and there are interoperability issues across user agents. Michael Puls II did ran some tests some time ago and posted these on this listserv: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0200.html As a separate question, it would be necessary for proper operation of XHR to always provide content-type and content-length headers when providing a response entity body. Does Firefox provide these headers when the XHR object is used to retrieve local file: representations? Again, this isn't standard behavior, and Firefox doesn't provide these headers over file:// Separately, I disagree with Anne about restrictions on XHR, but don't wish to preempt that discussion till filedata: is better defined. -- A*
Re: New FileAPI Draft | was Re: FileAPI feedback
On Mon, 17 Aug 2009 20:12:50 -0400, Arun Ranganathan a...@mozilla.com wrote: Nikunj R. Mehta wrote: On Aug 12, 2009, at 7:29 AM, Arun Ranganathan wrote: Gregg Tavares wrote: How about this? Why make a new API for getting the contents of a file (local or otherwise) when we already have one which is XHR? What if FileList was just array of File objects where each File object is just a URL in the format filedata: uuid, filename Then you can use that URL anywhere in HTML a URL is valid. script, img, audio, video, css, AND XHR That would mean you wouldn't be adding a new API to get the contents of a file. If you want the contents just use XHR and use the URL from the File in the FileList. You could add a few more functions to XHR like request.getAsDataURL(), request.getAsTextInEncodiing(), etc. if need be if they are neede Today, it's possible to use XHR from privileged web content in Firefox to access file:// URLs; the drawback is that these don't return HTTP responses, and of course there are security considerations. As stated, the XHR algorithm for open() [1] allows relative references and resolves them relative to the document base URI. Does that mean that if the document was loaded using file: uri, then the XHR could be used for loading a file? Currently, this behavior is not standard, and there are interoperability issues across user agents. Michael Puls II did ran some tests some time ago and posted these on this listserv: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0200.html I have a more specific proposal about simulating HTTP status codes for file: operations that I'll be posting soon. I also have an alternate proposal to post soon for a simple FileReader api to replace the local file loading part of DOM3 LS, document.load and XHR. I also have some questions about using the new FileAPI to load files on file:// without the use of input type=file. (Will post these things in new threads soon.) -- Michael
Re: New FileAPI Draft | was Re: FileAPI feedback
Nikunj R. Mehta wrote: On Aug 5, 2009, at 6:55 PM, Jonas Sicking wrote: What's the use-case for getAsBase64? I have another use case for this. The Atom Publishing protocol per RFC 5023 [1] accepts inline binary data represented in base 64 encoding. In order to submit binary inline content in an Atom entry to an Atom server, it would be necessary to getAsBase64() Specifically, atom:entry can contain Base64-encoded content [2]; I'm not sure it allows *other ways* to submit inline binary content. I suppose one reason to keep the ability to get data in Base64 is for legacy reasons, since it happens to be a convenient way to get binary stuff into web content (and ultimately onto servers). The problem is that it is not as useful within webapps (at least, not as useful as binary content). Use cases submitted till now involve *submitting* binary content in Base64 to servers that can handle Base64, but not doing anything useful with Base64 *within* the web app (where I suspect the first thing someone might do is to convert it to a binary string again). I suppose one reason to keep it around is if: 1. Web app asks user to pick file 2. File is picked and extracted as Base64 3. Atom container with Base64 is submitted via XHR using the Atom Publishing Protocol [1]. I'm willing to keep a way to get data as Base64 around for such cases. -- A* Nikunj http://o-micron.blogspot.com [1] http://tools.ietf.org/html/rfc5023 [2] http://www.ietf.org/rfc/rfc4287.txt
Re: [File API] events vs callbacks (was: Re: New FileAPI Draft | was Re: FileAPI feedback)
On Fri, Aug 14, 2009 at 5:27 PM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Fri, Aug 14, 2009 at 3:49 PM, Jonas Sickingjo...@sicking.cc wrote:
On Fri, Aug 14, 2009 at 11:09 AM, Garrett Smithdhtmlkitc...@gmail.com
wrote:
On Mon, Aug 10, 2009 at 6:48 PM, Jonas Sickingjo...@sicking.cc wrote:
On Sat, Aug 8, 2009 at 9:37 AM, Garrett Smithdhtmlkitc...@gmail.com
wrote:
On Thu, Aug 6, 2009 at 11:31 AM, Jonas Sickingjo...@sicking.cc wrote:
On Wed, Aug 5, 2009 at 4:26 AM, Anne van Kesterenann...@opera.com
wrote:
On Wed, 05 Aug 2009 10:04:28 +0200, Arun Ranganathan a...@mozilla.com
wrote:
In the case of file read APIs, simply getting the data asynchronously
is
more convenient than using events. There is no intrigue at work here,
merely disagreement.
Who said getting data asynchronuosly is less convenient than using
events? I am not sure what that really means, but I am pretty sure
this is not a debate of using events vs. getting data
asynchronously.
Arun also argued previously: Callbacks are used so that these APIs
can behave asynchronously. The callback parameter has nothing
whatsoever to do with the API being asynchronous. How the callback is
registered is a design decision.
It was determined and agreed that reading a file should be
asynchronous. We should all be on the same page now.
Event callbacks are asynchronous. So, it is not a matter of arguing
synchronous events with asynchronous callback.
Problems with the existing design were already explained in the other
thread. Some of those problems were not acknowledged by the author.
There is not a consensus.
I would like to register a Formal Objection.
The File API design does not provide for standard callback
registration, but instead uses its own callback registration
mechanism. This limits the flexibility of implementation code and
limits extensibility of the API.
I could imagine that for reading data you might want to have events
though
so that in the future we can introduce progress events if that is found
necessary. E.g. if the actual file is not on the same computer as where
the
user selected it.
An API should generally be extensible.
Problem: The File API couples the call to read with the callback.
This violates OCP.
This is easily achievable by decouple the call to read from the
notification that the reading has completed.
The way to solve this problem entails the reader implementing either:
1) DOM Events
2) DOM Event handler properties
Skipping this part in order to get to the meat of the discussion which
is the actual proposal. I hope that this is ok. I assure you I read
all of the above.
Do you have a proposal for what this would look I'm not excited
about creating something that's significantly more complex than the
current API.
Removing the callback parameter and using a Reader was proposed in
that other thread. While it was argued that it had fewer LOC in the
simplest cases, it wasn't ever demonstrated as being more complicated.
The current possibility is to have just a callback:-
file.getAsDataURL(handleURL);
- and then check the status to see if it was successful.
How to implement multiple callbacks with that?
Multiple callbacks can be implemented with the current draft proposal,
e.g. ala file.read( callWhenDone ), but not without a good amount of
work. It would entail the program to create its own Reader that is
itself an EventPublisher[1] Depending on the situation, that could be
elegant or could be extra plumbing.
I so far have not seen any use case that required the need for
multiple callbacks, or indeed where multiple callbacks would even be
useful. The use case from the previous thread seemed to be to hide UI
once file loading was done, no matter if the load succeeded or not.
The easiest way to do that seems to be:
file.getAsBinary(myHandler);
function myHandler(data, error) {
... hide UI ...;
if (error) {
... handle error ...
return;
}
... process data ...
}
Regarding the callback function you've written, one parameter should
be all that is necessary.
- function myHandler(data, error)
+ function myHandler(ev) {
...
if(ev.readFailure) {
...
} else {
var data = ev.data;
}
}
I disagree that adding if-else's to the callback is better. It gives
the callback more generic functionality.
The added conditional logic increases the indentation and makes it
harder to see what the method is doing. Testing that callback is going
to require many tests, to cover all conditions. Now it's a toy
example, but imagine the function gets longer (as functions tend to
do) and becomes something like 50 LOC and has more indentations. Isn't
it better to have a couple of clearly defined methods that follow SRP?
If we used a reader (as proposed below) together with progress events,
you'd get code like:
reader = getAReader();
reader.onerror = function() {
... handle error ...
}
Re: [File API] events vs callbacks (was: Re: New FileAPI Draft | was Re: FileAPI feedback)
On Mon, Aug 10, 2009 at 6:48 PM, Jonas Sickingjo...@sicking.cc wrote:
On Sat, Aug 8, 2009 at 9:37 AM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Thu, Aug 6, 2009 at 11:31 AM, Jonas Sickingjo...@sicking.cc wrote:
On Wed, Aug 5, 2009 at 4:26 AM, Anne van Kesterenann...@opera.com wrote:
On Wed, 05 Aug 2009 10:04:28 +0200, Arun Ranganathan a...@mozilla.com
wrote:
In the case of file read APIs, simply getting the data asynchronously is
more convenient than using events. There is no intrigue at work here,
merely disagreement.
Who said getting data asynchronuosly is less convenient than using
events? I am not sure what that really means, but I am pretty sure
this is not a debate of using events vs. getting data
asynchronously.
Arun also argued previously: Callbacks are used so that these APIs
can behave asynchronously. The callback parameter has nothing
whatsoever to do with the API being asynchronous. How the callback is
registered is a design decision.
It was determined and agreed that reading a file should be
asynchronous. We should all be on the same page now.
Event callbacks are asynchronous. So, it is not a matter of arguing
synchronous events with asynchronous callback.
Problems with the existing design were already explained in the other
thread. Some of those problems were not acknowledged by the author.
There is not a consensus.
I would like to register a Formal Objection.
The File API design does not provide for standard callback
registration, but instead uses its own callback registration
mechanism. This limits the flexibility of implementation code and
limits extensibility of the API.
I could imagine that for reading data you might want to have events though
so that in the future we can introduce progress events if that is found
necessary. E.g. if the actual file is not on the same computer as where the
user selected it.
An API should generally be extensible.
Problem: The File API couples the call to read with the callback.
This violates OCP.
This is easily achievable by decouple the call to read from the
notification that the reading has completed.
The way to solve this problem entails the reader implementing either:
1) DOM Events
2) DOM Event handler properties
Skipping this part in order to get to the meat of the discussion which
is the actual proposal. I hope that this is ok. I assure you I read
all of the above.
Do you have a proposal for what this would look I'm not excited
about creating something that's significantly more complex than the
current API.
Removing the callback parameter and using a Reader was proposed in
that other thread. While it was argued that it had fewer LOC in the
simplest cases, it wasn't ever demonstrated as being more complicated.
The current possibility is to have just a callback:-
file.getAsDataURL(handleURL);
- and then check the status to see if it was successful.
How to implement multiple callbacks with that?
Multiple callbacks can be implemented with the current draft proposal,
e.g. ala file.read( callWhenDone ), but not without a good amount of
work. It would entail the program to create its own Reader that is
itself an EventPublisher[1] Depending on the situation, that could be
elegant or could be extra plumbing.
I so far have not seen any use case that required the need for
multiple callbacks, or indeed where multiple callbacks would even be
useful. The use case from the previous thread seemed to be to hide UI
once file loading was done, no matter if the load succeeded or not.
The easiest way to do that seems to be:
file.getAsBinary(myHandler);
function myHandler(data, error) {
... hide UI ...;
if (error) {
... handle error ...
return;
}
... process data ...
}
Regarding the callback function you've written, one parameter should
be all that is necessary.
- function myHandler(data, error)
+ function myHandler(ev) {
...
if(ev.readFailure) {
...
} else {
var data = ev.data;
}
}
I disagree that adding if-else's to the callback is better. It gives
the callback more generic functionality.
The added conditional logic increases the indentation and makes it
harder to see what the method is doing. Testing that callback is going
to require many tests, to cover all conditions. Now it's a toy
example, but imagine the function gets longer (as functions tend to
do) and becomes something like 50 LOC and has more indentations. Isn't
it better to have a couple of clearly defined methods that follow SRP?
If we used a reader (as proposed below) together with progress events,
you'd get code like:
reader = getAReader();
reader.onerror = function() {
... handle error ...
}
reader.onload = function() {
... process data ...
}
reader.onloadend = function() {
... hide UI ...
}
reader.read(file);
Only where one wanted it. If you read what I wrote:-
var reader = getAReader(); // etc.
reader.oncomplete = readDone;
Re: [File API] events vs callbacks (was: Re: New FileAPI Draft | was Re: FileAPI feedback)
I think at this point I would like to stop having meta-discussions about which coding pattern is the cleanest one. I think we simply disagree there. In order to move forward I think we need to compare actual proposals of APIs and see how well they solve various use cases. As far as I can see we have three concrete proposals: A) The proposal in the current draft [1] B) The proposal from Olli [2] C) The proposal from me [3] I have so far not seen a concrete proposal from you, though what you have described has sounded similar to [3], but with some properties with different names (oncomplete rather than onloadend I think?) The use cases that have been discussed so far are: 1. Reading data from the file in various formats (data-url, binary, text) 2. Progress notifications while reading the file 3. Ability to hide UI once reading is done, weather reading succeeded or not. Do this without having to duplicate code. 4. Ability to pass File object around without risking other users of the file interfering with your reads. It seems to me that [1] supports 1 and 3. 2 isn't satisfied because there are no progress notifications. It has been suggested (by me and Arun) that this can be fixed, but no proposal has been made yet. 4 isn't satisfied because there is a risk that someone else calls cancelReads, which aborts your reads. [2] satisfies 1, 2 and 3. 4 isn't satisfied because if anyone calls a getAsX function, then the events from that read will be intermingeled with your events. Alternatively, if we don't allow parallel reads, if someone else has started a read then you are blocked from reading which means that 4 still isn't satisfied. [3] satisfies 1, 2, 3 and 4, however it is the most complex API out of any API proposed yet (not surprising as that tends to happen when you try to satisfy all use cases :) ). / Jonas [1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0539.html [3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0565.html P.S. I assure you I've read your full email below, even though I haven't responded to the individual parts. On Fri, Aug 14, 2009 at 11:09 AM, Garrett Smithdhtmlkitc...@gmail.com wrote: On Mon, Aug 10, 2009 at 6:48 PM, Jonas Sickingjo...@sicking.cc wrote: On Sat, Aug 8, 2009 at 9:37 AM, Garrett Smithdhtmlkitc...@gmail.com wrote: On Thu, Aug 6, 2009 at 11:31 AM, Jonas Sickingjo...@sicking.cc wrote: On Wed, Aug 5, 2009 at 4:26 AM, Anne van Kesterenann...@opera.com wrote: On Wed, 05 Aug 2009 10:04:28 +0200, Arun Ranganathan a...@mozilla.com wrote: In the case of file read APIs, simply getting the data asynchronously is more convenient than using events. There is no intrigue at work here, merely disagreement. Who said getting data asynchronuosly is less convenient than using events? I am not sure what that really means, but I am pretty sure this is not a debate of using events vs. getting data asynchronously. Arun also argued previously: Callbacks are used so that these APIs can behave asynchronously. The callback parameter has nothing whatsoever to do with the API being asynchronous. How the callback is registered is a design decision. It was determined and agreed that reading a file should be asynchronous. We should all be on the same page now. Event callbacks are asynchronous. So, it is not a matter of arguing synchronous events with asynchronous callback. Problems with the existing design were already explained in the other thread. Some of those problems were not acknowledged by the author. There is not a consensus. I would like to register a Formal Objection. The File API design does not provide for standard callback registration, but instead uses its own callback registration mechanism. This limits the flexibility of implementation code and limits extensibility of the API. I could imagine that for reading data you might want to have events though so that in the future we can introduce progress events if that is found necessary. E.g. if the actual file is not on the same computer as where the user selected it. An API should generally be extensible. Problem: The File API couples the call to read with the callback. This violates OCP. This is easily achievable by decouple the call to read from the notification that the reading has completed. The way to solve this problem entails the reader implementing either: 1) DOM Events 2) DOM Event handler properties Skipping this part in order to get to the meat of the discussion which is the actual proposal. I hope that this is ok. I assure you I read all of the above. Do you have a proposal for what this would look I'm not excited about creating something that's significantly more complex than the current API. Removing the callback parameter and using a Reader was proposed in that other thread. While it was argued that it had fewer LOC in the simplest cases, it
Re: [File API] events vs callbacks (was: Re: New FileAPI Draft | was Re: FileAPI feedback)
On Fri, Aug 14, 2009 at 3:49 PM, Jonas Sickingjo...@sicking.cc wrote:
On Fri, Aug 14, 2009 at 11:09 AM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Mon, Aug 10, 2009 at 6:48 PM, Jonas Sickingjo...@sicking.cc wrote:
On Sat, Aug 8, 2009 at 9:37 AM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Thu, Aug 6, 2009 at 11:31 AM, Jonas Sickingjo...@sicking.cc wrote:
On Wed, Aug 5, 2009 at 4:26 AM, Anne van Kesterenann...@opera.com wrote:
On Wed, 05 Aug 2009 10:04:28 +0200, Arun Ranganathan a...@mozilla.com
wrote:
In the case of file read APIs, simply getting the data asynchronously is
more convenient than using events. There is no intrigue at work here,
merely disagreement.
Who said getting data asynchronuosly is less convenient than using
events? I am not sure what that really means, but I am pretty sure
this is not a debate of using events vs. getting data
asynchronously.
Arun also argued previously: Callbacks are used so that these APIs
can behave asynchronously. The callback parameter has nothing
whatsoever to do with the API being asynchronous. How the callback is
registered is a design decision.
It was determined and agreed that reading a file should be
asynchronous. We should all be on the same page now.
Event callbacks are asynchronous. So, it is not a matter of arguing
synchronous events with asynchronous callback.
Problems with the existing design were already explained in the other
thread. Some of those problems were not acknowledged by the author.
There is not a consensus.
I would like to register a Formal Objection.
The File API design does not provide for standard callback
registration, but instead uses its own callback registration
mechanism. This limits the flexibility of implementation code and
limits extensibility of the API.
I could imagine that for reading data you might want to have events
though
so that in the future we can introduce progress events if that is found
necessary. E.g. if the actual file is not on the same computer as where
the
user selected it.
An API should generally be extensible.
Problem: The File API couples the call to read with the callback.
This violates OCP.
This is easily achievable by decouple the call to read from the
notification that the reading has completed.
The way to solve this problem entails the reader implementing either:
1) DOM Events
2) DOM Event handler properties
Skipping this part in order to get to the meat of the discussion which
is the actual proposal. I hope that this is ok. I assure you I read
all of the above.
Do you have a proposal for what this would look I'm not excited
about creating something that's significantly more complex than the
current API.
Removing the callback parameter and using a Reader was proposed in
that other thread. While it was argued that it had fewer LOC in the
simplest cases, it wasn't ever demonstrated as being more complicated.
The current possibility is to have just a callback:-
file.getAsDataURL(handleURL);
- and then check the status to see if it was successful.
How to implement multiple callbacks with that?
Multiple callbacks can be implemented with the current draft proposal,
e.g. ala file.read( callWhenDone ), but not without a good amount of
work. It would entail the program to create its own Reader that is
itself an EventPublisher[1] Depending on the situation, that could be
elegant or could be extra plumbing.
I so far have not seen any use case that required the need for
multiple callbacks, or indeed where multiple callbacks would even be
useful. The use case from the previous thread seemed to be to hide UI
once file loading was done, no matter if the load succeeded or not.
The easiest way to do that seems to be:
file.getAsBinary(myHandler);
function myHandler(data, error) {
... hide UI ...;
if (error) {
... handle error ...
return;
}
... process data ...
}
Regarding the callback function you've written, one parameter should
be all that is necessary.
- function myHandler(data, error)
+ function myHandler(ev) {
...
if(ev.readFailure) {
...
} else {
var data = ev.data;
}
}
I disagree that adding if-else's to the callback is better. It gives
the callback more generic functionality.
The added conditional logic increases the indentation and makes it
harder to see what the method is doing. Testing that callback is going
to require many tests, to cover all conditions. Now it's a toy
example, but imagine the function gets longer (as functions tend to
do) and becomes something like 50 LOC and has more indentations. Isn't
it better to have a couple of clearly defined methods that follow SRP?
If we used a reader (as proposed below) together with progress events,
you'd get code like:
reader = getAReader();
reader.onerror = function() {
... handle error ...
}
reader.onload = function() {
... process data ...
}
reader.onloadend = function()
Re: New FileAPI Draft | was Re: FileAPI feedback
Gregg Tavares wrote: How about this? Why make a new API for getting the contents of a file (local or otherwise) when we already have one which is XHR? What if FileList was just array of File objects where each File object is just a URL in the format filedata: uuid, filename Then you can use that URL anywhere in HTML a URL is valid. script, img, audio, video, css, AND XHR That would mean you wouldn't be adding a new API to get the contents of a file. If you want the contents just use XHR and use the URL from the File in the FileList. You could add a few more functions to XHR like request.getAsDataURL(), request.getAsTextInEncodiing(), etc. if need be if they are neede Today, it's possible to use XHR from privileged web content in Firefox to access file:// URLs; the drawback is that these don't return HTTP responses, and of course there are security considerations. I'm not sure it is necessary to reuse the XHR primitive for general file access (though I find the idea of not distinguishing remote files from local pretty attractive), but I have defined the filedata: URL scheme to return some HTTP response codes [1], so that it can be used with XHR. What is permitted and what is not is bound to be a controversial discussion :-) -- A* [1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Re: New FileAPI Draft | was Re: FileAPI feedback
splice should synchronously return a new FileData object. No need for asynchronous callback since no IO occurs. Done, though I used Anne's suggestion to make it an attribute. Whoops, no I didn't mean Anne's suggestion for slice -- I meant it for getAsURL. Also the current draft is: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Re: New FileAPI Draft | was Re: FileAPI feedback
On Wed, Aug 12, 2009 at 7:42 AM, Arun Ranganathana...@mozilla.com wrote: What's the use-case for getAsBase64? It's generally hard to encode files and to send them to servers. While Data URLs give developers a convenient way to work with Base64, URL length limitations across user agents make it pretty tough to use in practice. And while we do have a getAsBinaryString now, I still think getAsBase64 is important because of the fact that many server environments provide ways to work with Base64 strings (e.g. PHP's base64_decode method, which is really useful along with an XHR that submits Base64 encoded strings, as well as Perl's decode_base64, etc.). It's a convenient way to encode file data and servers work with it out of the box . The drawback is that it increases the data size from the original file. The fact that servers can work with base64 encoded strings is not a reason for wanting to do so. If you want to send data to the server it seems much more desirable to send the raw data to the server. Unless you are arguing that there are servers out there that can't consume the raw data, but that could consume base64 encoded data? in other words, because the server could consume it is not a good reason to send data in a particular format to the server. The reason should be because there's advantage X with sending in in that format. So far I don't see an advantage X with base64. / Jonas
Re: [File API] events vs callbacks (was: Re: New FileAPI Draft | was Re: FileAPI feedback)
On Sat, Aug 8, 2009 at 9:37 AM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Thu, Aug 6, 2009 at 11:31 AM, Jonas Sickingjo...@sicking.cc wrote:
On Wed, Aug 5, 2009 at 4:26 AM, Anne van Kesterenann...@opera.com wrote:
On Wed, 05 Aug 2009 10:04:28 +0200, Arun Ranganathan a...@mozilla.com
wrote:
In the case of file read APIs, simply getting the data asynchronously is
more convenient than using events. There is no intrigue at work here,
merely disagreement.
Who said getting data asynchronuosly is less convenient than using
events? I am not sure what that really means, but I am pretty sure
this is not a debate of using events vs. getting data
asynchronously.
Arun also argued previously: Callbacks are used so that these APIs
can behave asynchronously. The callback parameter has nothing
whatsoever to do with the API being asynchronous. How the callback is
registered is a design decision.
It was determined and agreed that reading a file should be
asynchronous. We should all be on the same page now.
Event callbacks are asynchronous. So, it is not a matter of arguing
synchronous events with asynchronous callback.
Problems with the existing design were already explained in the other
thread. Some of those problems were not acknowledged by the author.
There is not a consensus.
I would like to register a Formal Objection.
The File API design does not provide for standard callback
registration, but instead uses its own callback registration
mechanism. This limits the flexibility of implementation code and
limits extensibility of the API.
I could imagine that for reading data you might want to have events though
so that in the future we can introduce progress events if that is found
necessary. E.g. if the actual file is not on the same computer as where the
user selected it.
An API should generally be extensible.
Problem: The File API couples the call to read with the callback.
This violates OCP.
This is easily achievable by decouple the call to read from the
notification that the reading has completed.
The way to solve this problem entails the reader implementing either:
1) DOM Events
2) DOM Event handler properties
Skipping this part in order to get to the meat of the discussion which
is the actual proposal. I hope that this is ok. I assure you I read
all of the above.
Do you have a proposal for what this would look I'm not excited
about creating something that's significantly more complex than the
current API.
Removing the callback parameter and using a Reader was proposed in
that other thread. While it was argued that it had fewer LOC in the
simplest cases, it wasn't ever demonstrated as being more complicated.
The current possibility is to have just a callback:-
file.getAsDataURL(handleURL);
- and then check the status to see if it was successful.
How to implement multiple callbacks with that?
Multiple callbacks can be implemented with the current draft proposal,
e.g. ala file.read( callWhenDone ), but not without a good amount of
work. It would entail the program to create its own Reader that is
itself an EventPublisher[1] Depending on the situation, that could be
elegant or could be extra plumbing.
I so far have not seen any use case that required the need for
multiple callbacks, or indeed where multiple callbacks would even be
useful. The use case from the previous thread seemed to be to hide UI
once file loading was done, no matter if the load succeeded or not.
The easiest way to do that seems to be:
file.getAsBinary(myHandler);
function myHandler(data, error) {
... hide UI ...;
if (error) {
... handle error ...
return;
}
... process data ...
}
If we used a reader (as proposed below) together with progress events,
you'd get code like:
reader = getAReader();
reader.onerror = function() {
... handle error ...
}
reader.onload = function() {
... process data ...
}
reader.onloadend = function() {
... hide UI ...
}
reader.read(file);
I can't really say that this seems like a big benefit.
The proposed Reader solution:
var reader = getAReader(); // etc.
reader.oncomplete = readDone;
reader.read( file );
This allows new features to be added, allowing forwards changes
without changing existing features. This also has a benefit of
providing an Interface (Reader) that 1) reads, and 2) fires events.
The reader could be any sort of reader.
What do you mean by The reader could be any sort of reader?
Using a Reader decouples the type of read from the file object.
The other proposed solution was to have the events on the file, not as
a separate Reader.
file.oncomplete = contentsRead;
file.readAsDataUrl();
file.readAsText();
That puts the context on the file. This means the callback must check
the result of the type of read. In the example above, contentsRead
would have to know something about the data read (is it a URL or
Text?) and would end up having if else statements that call other
Re: New FileAPI Draft | was Re: FileAPI feedback
On Thu, 06 Aug 2009 22:05:55 +0200, Gregg Tavares g...@google.com wrote: well, here's an issue that NOT doing it through XMLHttpRequest seems to bring up. Say I'm writing word processor or blog posting software. I want to add the feature where the user can import an RTF file and I'm going to parse the file in JavaScript and pull out the text and formatting in stick it in their current document. If you do it through XMLHttpRequest then there is one path the get the data. One way or another the user ends up providing an URL. That url could be http://foo.com/mydoc.rtf; or it could be filedata: uuid, mydoc.rtf but I pass that to XMLHttpRequest and I get back the data in a consistent way. Otherwise, if you go forward with getting the data through FileData.get??? methods, there are now two code paths needed, 2 ways to setup callbacks, 2 ways to get progress events, 2 ways to deal with errors, etc. That seems less than ideal to me. The problem I have with it is that XMLHttpRequest provides an HTTP API. Not an API got to file data. There's no need for setting the request method, request headers, request body, etc. when trying to get the data of file. You already need different code paths to obtain that URI in the first place and since they are effectively different processes it might even make sense to have different UI and code for them as well, including things like error messages. E.g. for HTTP network errors might occur while with reading files the file might just have been deleted, moved, etc. -- Anne van Kesteren http://annevankesteren.nl/
Re: [File API] events vs callbacks (was: Re: New FileAPI Draft | was Re: FileAPI feedback)
On Thu, Aug 6, 2009 at 11:31 AM, Jonas Sickingjo...@sicking.cc wrote: On Wed, Aug 5, 2009 at 4:26 AM, Anne van Kesterenann...@opera.com wrote: On Wed, 05 Aug 2009 10:04:28 +0200, Arun Ranganathan a...@mozilla.com wrote: In the case of file read APIs, simply getting the data asynchronously is more convenient than using events. There is no intrigue at work here, merely disagreement. Who said getting data asynchronuosly is less convenient than using events? I am not sure what that really means, but I am pretty sure this is not a debate of using events vs. getting data asynchronously. Arun also argued previously: Callbacks are used so that these APIs can behave asynchronously. The callback parameter has nothing whatsoever to do with the API being asynchronous. How the callback is registered is a design decision. It was determined and agreed that reading a file should be asynchronous. We should all be on the same page now. Event callbacks are asynchronous. So, it is not a matter of arguing synchronous events with asynchronous callback. Problems with the existing design were already explained in the other thread. Some of those problems were not acknowledged by the author. There is not a consensus. I would like to register a Formal Objection. The File API design does not provide for standard callback registration, but instead uses its own callback registration mechanism. This limits the flexibility of implementation code and limits extensibility of the API. I could imagine that for reading data you might want to have events though so that in the future we can introduce progress events if that is found necessary. E.g. if the actual file is not on the same computer as where the user selected it. An API should generally be extensible. Problem: The File API couples the call to read with the callback. This violates OCP. This is easily achievable by decouple the call to read from the notification that the reading has completed. The way to solve this problem entails the reader implementing either: 1) DOM Events 2) DOM Event handler properties Do you have a proposal for what this would look I'm not excited about creating something that's significantly more complex than the current API. Removing the callback parameter and using a Reader was proposed in that other thread. While it was argued that it had fewer LOC in the simplest cases, it wasn't ever demonstrated as being more complicated. The current possibility is to have just a callback:- file.getAsDataURL(handleURL); - and then check the status to see if it was successful. How to implement multiple callbacks with that? Multiple callbacks can be implemented with the current draft proposal, e.g. ala file.read( callWhenDone ), but not without a good amount of work. It would entail the program to create its own Reader that is itself an EventPublisher[1] Depending on the situation, that could be elegant or could be extra plumbing. The proposed Reader solution: var reader = getAReader(); // etc. reader.oncomplete = readDone; reader.read( file ); This allows new features to be added, allowing forwards changes without changing existing features. This also has a benefit of providing an Interface (Reader) that 1) reads, and 2) fires events. The reader could be any sort of reader. Using a Reader decouples the type of read from the file object. The other proposed solution was to have the events on the file, not as a separate Reader. file.oncomplete = contentsRead; file.readAsDataUrl(); file.readAsText(); That puts the context on the file. This means the callback must check the result of the type of read. In the example above, contentsRead would have to know something about the data read (is it a URL or Text?) and would end up having if else statements that call other functions. This was provided in Jonas' example of reading file raw data and as a data-url. / Jonas Regards, Garrett [1] An EventPublisher keeps track of subscribers (other callbacks), provides its own mechanism for registration), and fires events.
Re: New FileAPI Draft | was Re: FileAPI feedback
On Wed, Aug 5, 2009 at 8:08 PM, Garrett Smith dhtmlkitc...@gmail.comwrote:
On Wed, Aug 5, 2009 at 1:04 AM, Arun Ranganathana...@mozilla.com wrote:
Garrett Smith wrote:
Please show the subsequent use cases you've studied and please do
publish your studies.
What I meant by use cases was this exchange:
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0371.html
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0457.html
Those are the discussions of Events that you did not participate in.
Where is the complexity study?
In the case of changing UI indicators, using a common codepath for
success
as well as errors seemed more useful than multiple error callbacks.
Multiple error callbacks? Who brought that up? Are you making a Straw Man?
In the case of file read APIs, simply getting the data asynchronously is
more convenient than using events. There is no intrigue at work here,
merely disagreement.
Is it? In reading that discussion, I see no disagreement from you
whatsoever.
I see that you posted this new thread. You said you studied the use
cases and that your original design was best. We still have no
evidence that any studying has taken place. Please post the studies so
that they can be understood.
The route you chose makes a permanent design decision. Once done, it
can not be undone. If it goes through as is, the best case at that
point would be to start over.
I am not going to argue with hand-waving summations or the multiple
error handlers straw man.
Garrett
I probably have no understanding of the issue but casually glancing at
the discussion links above, can't you solve the multiple callback issue
by wrapping the callback in JavaScript?
If I understand correctly, a File is not an element nor is it attached to
the DOM so some random JavaScript can not do something like
document.getElementsByTagName('File');
In the DOM case multiple callbacks per event make some sense because
2 different pieces of code can find the same elements but in the File case
only
code can create a File object, some other random code can't go
searching for that object. That means the code that created the File object
can manage it however it sees fit including wrapping the entire thing in
a JavaScript object and having that object support multiple callbacks if it
wants
to.
Re: New FileAPI Draft | was Re: FileAPI feedback
On Thu, 06 Aug 2009 01:10:31 +0200, Gregg Tavares g...@google.com wrote: Why make a new API for getting the contents of a file (local or otherwise) when we already have one which is XHR? XHR does not do local data. It also does not do raw file data very well. What if FileList was just array of File objects where each File object is just a URL in the format filedata: uuid, filename Then you can use that URL anywhere in HTML a URL is valid. script, img, audio, video, css, AND XHR I agree that we need this functionality: http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/thread.html#msg67 I'm not sure if feeding it to XHR makes sense though. Especially if you just want to do a partial read there would be quite a bit of overhead. That would mean you wouldn't be adding a new API to get the contents of a file. If you want the contents just use XHR and use the URL from the File in the FileList. You could add a few more functions to XHR like request.getAsDataURL(), request.getAsTextInEncodiing(), etc. if need be if they are needed It's an interesting idea, but overloading XMLHTtpRequest in this way does not seem like a good idea to me. -- Anne van Kesteren http://annevankesteren.nl/
Re: [File API] events vs callbacks (was: Re: New FileAPI Draft | was Re: FileAPI feedback)
On Wed, Aug 5, 2009 at 4:26 AM, Anne van Kesterenann...@opera.com wrote: On Wed, 05 Aug 2009 10:04:28 +0200, Arun Ranganathan a...@mozilla.com wrote: In the case of file read APIs, simply getting the data asynchronously is more convenient than using events. There is no intrigue at work here, merely disagreement. I could imagine that for reading data you might want to have events though so that in the future we can introduce progress events if that is found necessary. E.g. if the actual file is not on the same computer as where the user selected it. Do you have a proposal for what this would look like? I'm not excited about creating something that's significantly more complex than the current API. / Jonas
Re: New FileAPI Draft | was Re: FileAPI feedback
On Thu, Aug 6, 2009 at 2:35 AM, Anne van Kesteren ann...@opera.com wrote: On Thu, 06 Aug 2009 10:53:31 +0200, Gregg Tavares g...@google.com wrote: On Thu, Aug 6, 2009 at 12:48 AM, Anne van Kesteren ann...@opera.com wrote: XHR does not do local data. It also does not do raw file data very well. I don't quite understand this comment. Isn't the point of these discussions how to extend browsers and HTML? XHR was just extended to support cross-site requests and new properties were added. Couldn't it be extended again to support local files (through the filedata: url system) and as well to support raw data? Sorry, it indeed could be extended in that way. I just think it is a bad idea. XMLHttpRequest provides an almost complete HTTP API and such a thing is completely different and way more complex than what is needed to read files from disk. In addition XMLHttpRequest is quite complex and overloading the whole object and all its members with this functionality is not worth saving a few members on the File/FileData objects. well, here's an issue that NOT doing it through XMLHttpRequest seems to bring up. Say I'm writing word processor or blog posting software. I want to add the feature where the user can import an RTF file and I'm going to parse the file in JavaScript and pull out the text and formatting in stick it in their current document. If you do it through XMLHttpRequest then there is one path the get the data. One way or another the user ends up providing an URL. That url could be http://foo.com/mydoc.rtf; or it could be filedata: uuid, mydoc.rtf but I pass that to XMLHttpRequest and I get back the data in a consistent way. Otherwise, if you go forward with getting the data through FileData.get??? methods, there are now two code paths needed, 2 ways to setup callbacks, 2 ways to get progress events, 2 ways to deal with errors, etc. That seems less than ideal to me. -- Anne van Kesteren http://annevankesteren.nl/
Re: New FileAPI Draft | was Re: FileAPI feedback
On Thu, Aug 6, 2009 at 1:05 PM, Gregg Tavaresg...@google.com wrote: On Thu, Aug 6, 2009 at 2:35 AM, Anne van Kesteren ann...@opera.com wrote: On Thu, 06 Aug 2009 10:53:31 +0200, Gregg Tavares g...@google.com wrote: On Thu, Aug 6, 2009 at 12:48 AM, Anne van Kesteren ann...@opera.com wrote: XHR does not do local data. It also does not do raw file data very well. I don't quite understand this comment. Isn't the point of these discussions how to extend browsers and HTML? XHR was just extended to support cross-site requests and new properties were added. Couldn't it be extended again to support local files (through the filedata: url system) and as well to support raw data? Sorry, it indeed could be extended in that way. I just think it is a bad idea. XMLHttpRequest provides an almost complete HTTP API and such a thing is completely different and way more complex than what is needed to read files from disk. In addition XMLHttpRequest is quite complex and overloading the whole object and all its members with this functionality is not worth saving a few members on the File/FileData objects. well, here's an issue that NOT doing it through XMLHttpRequest seems to bring up. Say I'm writing word processor or blog posting software. I want to add the feature where the user can import an RTF file and I'm going to parse the file in JavaScript and pull out the text and formatting in stick it in their current document. If you do it through XMLHttpRequest then there is one path the get the data. One way or another the user ends up providing an URL. That url could be http://foo.com/mydoc.rtf; or it could be filedata: uuid, mydoc.rtf but I pass that to XMLHttpRequest and I get back the data in a consistent way. Otherwise, if you go forward with getting the data through FileData.get??? methods, there are now two code paths needed, 2 ways to setup callbacks, 2 ways to get progress events, 2 ways to deal with errors, etc. That seems less than ideal to me. Note that with the current API it is actually possible to use XMLHttpRequest. If you use the getAsURL function, you get a URL which you can then pass to the XMLHttpRequest.open function. I don't believe we've fully looked at the implications of this, but at first glance it seems possible. / Jonas
Re: New FileAPI Draft | was Re: FileAPI feedback
Garrett Smith wrote: Please show the subsequent use cases you've studied and please do publish your studies. What I meant by use cases was this exchange: http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0371.html http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0457.html In the case of changing UI indicators, using a common codepath for success as well as errors seemed more useful than multiple error callbacks. In the case of file read APIs, simply getting the data asynchronously is more convenient than using events. There is no intrigue at work here, merely disagreement. -- A*
Re: New FileAPI Draft | was Re: FileAPI feedback
On Wed, Aug 5, 2009 at 1:47 AM, Arun Ranganathan a...@mozilla.com wrote: Gregg Tavares wrote: I'd really like to contribute to this as I'm helping implement WebGL and we need a way to get LOTS of data into WebGL. Hundreds of files per app. That said, there's a bunch of things I don't understand about the API *) Given that XMLHttpRequest is limited to a same domain policy Firefox 3.5 and Safari 4 support cross-domain XMLHttpRequest, mitigated by CORS. See, for example, http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/ but the img tag, audio tag, video tag, script tag and others are not, how do you resolve that with the FIle API? The File API is meant to talk to your local file system. It isn't a network download API, but it seems that's what you want :-). Perhaps I am misunderstanding your question? Sorry, I was told on the HTML5 list that this is where network downloads and archive support stuff belonged. It certain seems like a good fit to me. -- A*
Re: New FileAPI Draft | was Re: FileAPI feedback
Dmitry, the spec lists a use case about a web app that needs to send file(s) to the server programmatically. I happen to think lately about an E-mail app that can send attachments. FileData and its splice() method are useful here. I assume the XHR2 spec would get XHR.send(FileData) method. XHR2 provides progress events. Yes; I think in future, XHR2 will have an overloaded send method that can send a FileData object. - it'll need some way to save the File object to the Database field or a localStore value, so it can be stored there till uploaded by the worker or another page (I think this was discussed before, perhaps it's on the way into corresponding specs?) Of course, we don't want to write the content of the file into the Database, only opaquely roundtrip the 'file representing token'. Currently, the only file representing token that this specification allows for is the filedata://[UUID] URL, which is spec'd to be shortlived. Figuring out how to store file objects is a logical next step. I'm keen for us all to agree on some set of requirements as a v1 (and then release a FPWD), since the amount of new feature suggestions have been large (but very welcome ;-) ). - it'd be good to have the ability to 'snapshot' files. During the send/upload time the original files that user selected may 'disappear' from the locations captured. For example, they were photos on a flash card that got removed. It would be useful to (optionally) be able to make a copy of the file to some temporary location. This can be an async operation that comes back with a callback that gives a 'temp copy' File object (File.makeTemporaryCopy(callback)). Some limit on disk space could be set. They also will need to be removed at some point. This is another interesting feature. It seems unlikely that we'd all agree on a standardized disk space limitation, but there could be another way to reason through this. Again, I'm keen on shipping a v1 specification soon, and then iterating on it, either as part of this endeavor, or the Device API WG's File API (depending on how that shapes up). -- A*
Re: New FileAPI Draft | was Re: FileAPI feedback
Gregg Tavares wrote The File API is meant to talk to your local file system. It isn't a network download API, but it seems that's what you want :-). Perhaps I am misunderstanding your question? Sorry, I was told on the HTML5 list that this is where network downloads and archive support stuff belonged. It certain seems like a good fit to me. This is the right working group, and the right group of people. But the spec. you are commenting on is only for communication with the local file store, for use in conjunction with other parts of the web platform (e.g. XHR2). I think network downloads and other things are legitimate work items for the future in this WG, perhaps as further refinements to XHR2. Will Google propose them? -- A*
Re: New FileAPI Draft | was Re: FileAPI feedback
Hi, the spec lists a use case about a web app that needs to send file(s) to the server programmatically. I happen to think lately about an E-mail app that can send attachments. FileData and its splice() method are useful here. I assume the XHR2 spec would get XHR.send(FileData) method. XHR2 provides progress events. However, it seems some additional functionality is needed. For example, when sending e-mail with attachments, it may be good to 'release' the UI as soon as possible and have some sort of Outbox model when outgoing email and attachments are sent in the background, while user can close the page or navigate away, in which case the send could be resuming later when the app's page is open again - but it would be really bad to loose the unsent email. This is what comes to mind: - it'll need some way to save the File object to the Database field or a localStore value, so it can be stored there till uploaded by the worker or another page (I think this was discussed before, perhaps it's on the way into corresponding specs?) Of course, we don't want to write the content of the file into the Database, only opaquely roundtrip the 'file representing token'. - it'd be good to have the ability to 'snapshot' files. During the send/upload time the original files that user selected may 'disappear' from the locations captured. For example, they were photos on a flash card that got removed. It would be useful to (optionally) be able to make a copy of the file to some temporary location. This can be an async operation that comes back with a callback that gives a 'temp copy' File object (File.makeTemporaryCopy(callback)). Some limit on disk space could be set. They also will need to be removed at some point. Dmitry On Tue, Aug 4, 2009 at 6:55 PM, Arun Ranganathan a...@mozilla.com wrote: I have updated the draft of the File API, and welcome more review. Note that it is no longer called FileUpload since this term has become misleading. In particular, here are some of the issues addressed (and some not): Any reason you're using an XHTML file to edit this? Also, the indentation is awkward. http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html For what concerns the file as URI feature: What about reusing the cid scheme? After having looked at the RFCs for cid and mid schemes, I don't think the cid scheme is appropriate for our use case, since it is tightly tied to the notion of message body, which isn't necessarily true in all cases of file data. I have a proposal in this draft for the file as URL proposal (originally broached in IRC, but which has seen some discussion on the listserv). I'd welcome feedback on it, especially the processing model for these URLs. A simple ABNF using UUIDs as unique identifiers has been proposed here. File API should probably have some way to get only parts of the file. This has been added as a new method. Feedback welcome! [The existing design] limits the number of callbacks to one. That one callback can only be added in the invocation to read. Instead, allow multiple callbacks to be added with the DOM Events API While this was an intriguing suggestion (and seemed like it was a more powerful programming model), I wasn't convinced that it was needed for the File API. It did lead to a more complicated model that didn't seem to fully justify the power. However, I did study subsequent use cases, and eliminated error callbacks, allowing callbacks themselves to handle error conditions. Also, I introduced a cancelReads( ) which can be used with timeouts. I'm not convinced that an event model is necessary for asynchronous data accessors on file data; DOM events aren't useful in all cases. It's also worth nothing that the File API in general may be subject to further iteration in the Device API WG, which may introduce notions of write APIs. Note of course that whatever API supports ranges needs to ensure that the data isn't forcibly coerced into valid Unicode, as the underlying data for an image can include all sorts of patterns which aren't valid UTF8/16/ It was clear that getAsText was insufficient, so more asynchronous data accessor methods have been added. I think FileDialog is a bad idea. We already have UI for selecting multiple files: input type=file multiple. This has now been eliminated from this draft. I'm keen to move towards fpwd, and it seemed that FileDialog was needlessly controversial. I think it still is useful, and think it could be added later. -- A*
Re: New FileAPI Draft | was Re: FileAPI feedback
How about this? Why make a new API for getting the contents of a file (local or otherwise) when we already have one which is XHR? What if FileList was just array of File objects where each File object is just a URL in the format filedata: uuid, filename Then you can use that URL anywhere in HTML a URL is valid. script, img, audio, video, css, AND XHR That would mean you wouldn't be adding a new API to get the contents of a file. If you want the contents just use XHR and use the URL from the File in the FileList. You could add a few more functions to XHR like request.getAsDataURL(), request.getAsTextInEncodiing(), etc. if need be if they are needed
Re: New FileAPI Draft | was Re: FileAPI feedback
Oh, getAsURL should also be synchronous since no IO is occurring. / Jonas On Wed, Aug 5, 2009 at 6:55 PM, Jonas Sickingjo...@sicking.cc wrote: A few comments: Need to specify that all getAsX functions call the callback *asynchronously*. Also need to integrate this with the HTML5 event loop. getAsBinary should be called getAsBinaryString so that once we have a BinaryArray or some such we can add a getAsBinary that truly returns binary data. Need to specify the actual encoding for getAsBinary, i.e. that each character holds one byte, valued between 0-255. Obviously the filedata scheme needs to be defined in greater detail. What's the use-case for getAsBase64? splice should synchronously return a new FileData object. No need for asynchronous callback since no IO occurs. getAsBinaryString could take two optional |start| and |length| arguments to avoid having to use splice to read parts of a file. / Jonas On Tue, Aug 4, 2009 at 6:55 PM, Arun Ranganathana...@mozilla.com wrote: I have updated the draft of the File API, and welcome more review. Note that it is no longer called FileUpload since this term has become misleading. In particular, here are some of the issues addressed (and some not): Any reason you're using an XHTML file to edit this? Also, the indentation is awkward. http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html For what concerns the file as URI feature: What about reusing the cid scheme? After having looked at the RFCs for cid and mid schemes, I don't think the cid scheme is appropriate for our use case, since it is tightly tied to the notion of message body, which isn't necessarily true in all cases of file data. I have a proposal in this draft for the file as URL proposal (originally broached in IRC, but which has seen some discussion on the listserv). I'd welcome feedback on it, especially the processing model for these URLs. A simple ABNF using UUIDs as unique identifiers has been proposed here. File API should probably have some way to get only parts of the file. This has been added as a new method. Feedback welcome! [The existing design] limits the number of callbacks to one. That one callback can only be added in the invocation to read. Instead, allow multiple callbacks to be added with the DOM Events API While this was an intriguing suggestion (and seemed like it was a more powerful programming model), I wasn't convinced that it was needed for the File API. It did lead to a more complicated model that didn't seem to fully justify the power. However, I did study subsequent use cases, and eliminated error callbacks, allowing callbacks themselves to handle error conditions. Also, I introduced a cancelReads( ) which can be used with timeouts. I'm not convinced that an event model is necessary for asynchronous data accessors on file data; DOM events aren't useful in all cases. It's also worth nothing that the File API in general may be subject to further iteration in the Device API WG, which may introduce notions of write APIs. Note of course that whatever API supports ranges needs to ensure that the data isn't forcibly coerced into valid Unicode, as the underlying data for an image can include all sorts of patterns which aren't valid UTF8/16/ It was clear that getAsText was insufficient, so more asynchronous data accessor methods have been added. I think FileDialog is a bad idea. We already have UI for selecting multiple files: input type=file multiple. This has now been eliminated from this draft. I'm keen to move towards fpwd, and it seemed that FileDialog was needlessly controversial. I think it still is useful, and think it could be added later. -- A*
Re: New FileAPI Draft | was Re: FileAPI feedback
A few comments: Need to specify that all getAsX functions call the callback *asynchronously*. Also need to integrate this with the HTML5 event loop. getAsBinary should be called getAsBinaryString so that once we have a BinaryArray or some such we can add a getAsBinary that truly returns binary data. Need to specify the actual encoding for getAsBinary, i.e. that each character holds one byte, valued between 0-255. Obviously the filedata scheme needs to be defined in greater detail. What's the use-case for getAsBase64? splice should synchronously return a new FileData object. No need for asynchronous callback since no IO occurs. getAsBinaryString could take two optional |start| and |length| arguments to avoid having to use splice to read parts of a file. / Jonas On Tue, Aug 4, 2009 at 6:55 PM, Arun Ranganathana...@mozilla.com wrote: I have updated the draft of the File API, and welcome more review. Note that it is no longer called FileUpload since this term has become misleading. In particular, here are some of the issues addressed (and some not): Any reason you're using an XHTML file to edit this? Also, the indentation is awkward. http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html For what concerns the file as URI feature: What about reusing the cid scheme? After having looked at the RFCs for cid and mid schemes, I don't think the cid scheme is appropriate for our use case, since it is tightly tied to the notion of message body, which isn't necessarily true in all cases of file data. I have a proposal in this draft for the file as URL proposal (originally broached in IRC, but which has seen some discussion on the listserv). I'd welcome feedback on it, especially the processing model for these URLs. A simple ABNF using UUIDs as unique identifiers has been proposed here. File API should probably have some way to get only parts of the file. This has been added as a new method. Feedback welcome! [The existing design] limits the number of callbacks to one. That one callback can only be added in the invocation to read. Instead, allow multiple callbacks to be added with the DOM Events API While this was an intriguing suggestion (and seemed like it was a more powerful programming model), I wasn't convinced that it was needed for the File API. It did lead to a more complicated model that didn't seem to fully justify the power. However, I did study subsequent use cases, and eliminated error callbacks, allowing callbacks themselves to handle error conditions. Also, I introduced a cancelReads( ) which can be used with timeouts. I'm not convinced that an event model is necessary for asynchronous data accessors on file data; DOM events aren't useful in all cases. It's also worth nothing that the File API in general may be subject to further iteration in the Device API WG, which may introduce notions of write APIs. Note of course that whatever API supports ranges needs to ensure that the data isn't forcibly coerced into valid Unicode, as the underlying data for an image can include all sorts of patterns which aren't valid UTF8/16/ It was clear that getAsText was insufficient, so more asynchronous data accessor methods have been added. I think FileDialog is a bad idea. We already have UI for selecting multiple files: input type=file multiple. This has now been eliminated from this draft. I'm keen to move towards fpwd, and it seemed that FileDialog was needlessly controversial. I think it still is useful, and think it could be added later. -- A*
Re: New FileAPI Draft | was Re: FileAPI feedback
On Wed, Aug 5, 2009 at 1:04 AM, Arun Ranganathana...@mozilla.com wrote: Garrett Smith wrote: Please show the subsequent use cases you've studied and please do publish your studies. What I meant by use cases was this exchange: http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0371.html http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0457.html Those are the discussions of Events that you did not participate in. Where is the complexity study? In the case of changing UI indicators, using a common codepath for success as well as errors seemed more useful than multiple error callbacks. Multiple error callbacks? Who brought that up? Are you making a Straw Man? In the case of file read APIs, simply getting the data asynchronously is more convenient than using events. There is no intrigue at work here, merely disagreement. Is it? In reading that discussion, I see no disagreement from you whatsoever. I see that you posted this new thread. You said you studied the use cases and that your original design was best. We still have no evidence that any studying has taken place. Please post the studies so that they can be understood. The route you chose makes a permanent design decision. Once done, it can not be undone. If it goes through as is, the best case at that point would be to start over. I am not going to argue with hand-waving summations or the multiple error handlers straw man. Garrett
New FileAPI Draft | was Re: FileAPI feedback
I have updated the draft of the File API, and welcome more review. Note that it is no longer called FileUpload since this term has become misleading. In particular, here are some of the issues addressed (and some not): Any reason you're using an XHTML file to edit this? Also, the indentation is awkward. http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html For what concerns the file as URI feature: What about reusing the cid scheme? After having looked at the RFCs for cid and mid schemes, I don't think the cid scheme is appropriate for our use case, since it is tightly tied to the notion of message body, which isn't necessarily true in all cases of file data. I have a proposal in this draft for the file as URL proposal (originally broached in IRC, but which has seen some discussion on the listserv). I'd welcome feedback on it, especially the processing model for these URLs. A simple ABNF using UUIDs as unique identifiers has been proposed here. File API should probably have some way to get only parts of the file. This has been added as a new method. Feedback welcome! [The existing design] limits the number of callbacks to one. That one callback can only be added in the invocation to read. Instead, allow multiple callbacks to be added with the DOM Events API While this was an intriguing suggestion (and seemed like it was a more powerful programming model), I wasn't convinced that it was needed for the File API. It did lead to a more complicated model that didn't seem to fully justify the power. However, I did study subsequent use cases, and eliminated error callbacks, allowing callbacks themselves to handle error conditions. Also, I introduced a cancelReads( ) which can be used with timeouts. I'm not convinced that an event model is necessary for asynchronous data accessors on file data; DOM events aren't useful in all cases. It's also worth nothing that the File API in general may be subject to further iteration in the Device API WG, which may introduce notions of write APIs. Note of course that whatever API supports ranges needs to ensure that the data isn't forcibly coerced into valid Unicode, as the underlying data for an image can include all sorts of patterns which aren't valid UTF8/16/ It was clear that getAsText was insufficient, so more asynchronous data accessor methods have been added. I think FileDialog is a bad idea. We already have UI for selecting multiple files: input type=file multiple. This has now been eliminated from this draft. I'm keen to move towards fpwd, and it seemed that FileDialog was needlessly controversial. I think it still is useful, and think it could be added later. -- A*
