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
