On Aug 31, 2009, at 11:28 PM, Arun Ranganathan wrote:
Nikunj,
The File API is everyone's favorite API for feature requests as well
as programming style discussions :)
interface InputStream {
read(in DataHandler, [optional in] long long offset, [optional in]
long long length); abort();
attribute Function onerror;
}
There is lots that is attractive about InputStream, and I think that
it can be used in other specifications, especially when discussing
Camera APIs, streaming from web apps (conferencing) etc. I also
like the idea of DataHandler. When we define a byte primitive, it
can be used in conjunction with the stream interface. For
additional read features (fseek) this is also useful. I also
appreciate that you have pointed out in a subsequent email [1] that
it is possible to "sidestep the issue of dealing with bytes
directly." Managing bytes properly, with the right primitives, is
one reason why, despite having looked at the Java I/O APIs[2], I
went with something simpler. I think that we should have streams at
some point, and I'm amenable to looking at them in a subsequent
iteration of the File API. It's worth saying here that the appeal
of streams is for *multiple use cases* for both File API and other
APIs, and *not* because the Java I/O model is one we should
emulate. Programmer taste and choice about coining APIs is
subjective.
I respect your point on taste, however, I am more interested in
composability than the maturity of Java I/O. It would be useful to see
how you meet the following requirements:
1. incremental reading of a file's data
2. concurrent access to file data
3. access to all file metadata without needing to read the file
4. separation of error handling from file reading
All things being equal, I would prefer a model that, in order of
priority:
1. involves fewer steps, and
2. evolves nicely with file write and binary access, which are both
likely to be next evolution directions in this area.
Can you provide a comparison of your proposed approach with my
proposal for the above so that the WG can develop an informed opinion
about the proposals?
For a first version (which should replace http://www.w3.org/TR/file-upload/
, with a more meaningful name like "File API"), I think we should
address use cases around reads. Ian Fette has given us plenty of
other uses cases for consideration later on[3]. While my editor's
draft strove to address the use cases for file access with different
asynchronous data accessors, it was clear that it couldn't
gracefully account for progress events. Moreover, general feedback
favored a model that used events with a separate reader object that
allowed for progress events, and Jonas' alternative proposal does
this as well as resembles XHR [4]. While I'm reluctant to
sacrifice simplicity, I think moving in the direction of the
"Alternative File API"[4] reconciles use cases such as progress
events with calls for a reader/event model. FWIW, I disagree that
resemblance to XHR should be seen as "unwanted baggage" [5]. I
think it's desirable to resemble an API that has such widespread
usage!
This is arguable at best, since it seems to be an opinion not shared
by everyone, especially not the editor of XMLHttpRequest [1]. In fact,
there is no similarity to XHR in the current editor's draft, and I
wonder why those benefits were considered unimportant when drafting
previously.
While the web is inconsistent, event models are widely used, and
similarity between XHR and File API, which will be used in
conjunction anyway, is probably a good thing.
Can you explain in light of the objections I raised in [2], why the
"Alternative File API" is the right approach. I haven't seen any
replies to my points.
I'd say the following might be next steps:
1. Work on the File API but revise the editor's draft to reflect [4].
2. Collect use cases for further iterations of the File API, and
determine which WG should carry them forward. I'm in favor of
continuing in this WG as opposed to the Device API WG, but that is a
separate question.
3. In conjunction with 2., discuss security and platform issues
around proposals such as [6]. I'm interested in airing more
concrete proposals on this listserv.
-- A*
[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0757.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0729.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0900.html
[4] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0565.html
[5] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0749.html
[6] http://dev.w3.org/2006/webapi/fileio/fileIO.htm
Nikunj
http://o-micron.blogspot.com
[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0537.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0748.html
