Re: [FileAPI] Latest Revision of Editor's Draft

Ian Hickson wrote:
>> 3. The event model resembles that of XHR2, with a few differences.  
>> Notably, the APIs differ in their use of the 'loadend' ProgressEvent.
>>     
>
> I think this spec needs examples. I think the examples would show that the 
> current design requires far too many lines of code to do something that 
> really should only need one or two statements.
>
> (I think XHR is a very poor model to follow.)
>
>   


Currently, the introduction contains an example [1], which illustrates 
the event model design (use of FileReader).  Are there examples above 
and beyond what that illustrates that you'd like to see?  If so, 
suggestions are welcome.  I've committed to updating the specification 
with an example for Worker Threads, which makes use of a synchronous 
read API.

No argument from me that the current design in the editor's draft [1] 
requires more lines of code to read a file than the *initial* editor's 
draft which contained read methods with callbacks [2], but a lengthy 
thread (e.g. follow [3][4][5] and beyond) covering the desirability of 
callbacks vs. events (and particularly, progress events) resulted in the 
strawperson for the existing design [6].  I'll note that you didn't 
weigh in on these discussions then. 

I disagree with you that this constitutes "far too many lines of code" 
but I do agree with you that the present design is a more complex model 
than that in the original editor's draft [2].  The advantages are that 
it allows progress events, as well as the general benefits of an 
EventTarget (for adding event listeners).  There is also a separation of 
files from the objects that read from them.  There are definite 
trade-offs between simplicity and more complexity, which I've voiced 
before, but I am reconciled to the current proposal [1] since it covers 
desirable use cases.  There was general support for this, including 
recognition of the trade-offs (e.g. see [7][8], amongst others) which is 
why I proceeded with the current proposal.  The added complexity isn't 
*that great* and the model enables more power than the original proposal 
[2].

Regarding emulating XHR: general developer feedback we got was that it 
was a desirable model to follow, and that developers were familiar with 
it.  One suggestion, floated here, even suggested extending *XHR itself* 
to read files [9] (which there was general disagreement with, given the 
impulse to separate network APIs from file ones, which don't require 
network capabilities).  Given that we've gone down the path of using 
progress events and separating files from the objects that read from 
them, I do not agree that XHR is a very poor model to follow; rather, it 
is a popular model with a fair amount of developer familiarity, and has 
been wrapped by several libraries to offer even higher level 
abstractions for network activity.
>> 4. A suggestion to *not* have a separate scheme ("filedata:") in lieu of 
>> urn:uuid:<uuid>[2] has been the basis of a rewrite of that feature in 
>> this version of the specification.
>>     
> I would like to see implementation feedback on this. I don't understand 
> why we would want to assign semantics to urn:uuid: URLs that are so 
> specific -- that seems completely wrong. It also seems really awkward from 
> an implementation perspective to forgo the normal extension mechanism 
> (schemes) and have implementations give special (and non-trivial) 
> semantics to a subset of another scheme. Why are we doing this?
>   

In general, this area is the one most likely to be fraught with contention.

For what it's worth, we started with a separate scheme called filedata:  
[2], modeled after urn:uuid.  (And you don't strictly need UUIDs -- any 
identifier will do -- but it seemed advantageous to standardize an 
easily coinable identifier).   Can you explain why a *new scheme* is 
better than reusing an *existing scheme?*  The use case -- to have 
"time-bound" ways to access file data on the web platform everywhere a 
URL is used -- can probably be addressed with an existing scheme.  
Coining a new scheme is non-trivial; is it absolutely necessary here?

Your point about reusing a subset of HTTP for urn:uuid is valid, though, 
and I've left this as an editor's note.  We could have this behave like 
a new and improved file:///, and specify how it works *without* status 
codes.  We could merely specify that the urn:uuid resource is retrieved 
if valid (namely, that it meets the origin and lifetime stipulations), 
or nothing is returned if invalid.  Would this allay your queasiness 
about reusing urn:uuid?  Use cases for why request-response status codes 
are needed for file retrieval would be useful.

-- A*
[1] http://dev.w3.org/2006/webapi/FileAPI/
[2] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0539.html
[4] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0547.html
[5] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0551.html
[6] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0565.html
[7] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0664.html
[8] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0685.html
[9] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0492.html

Received on Tuesday, 27 October 2009 20:20:57 UTC