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

Reply via email to