Re: File API to separate reading from files

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.

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!  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.

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

Received on Tuesday, 1 September 2009 06:28:43 UTC