Re: File API to separate reading from files

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

Received on Tuesday, 1 September 2009 07:05:30 UTC