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

On Tue, Oct 27, 2009 at 12:36 AM, Ian Hickson <ian@hixie.ch> 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.)

I was as surprised as you, but the feedback we consistently received,
both here and when talking directly to developers, was that using an
events-based model was preferable to using callbacks. We also received
the feedback that following XHR was good because authors were used to
this model.

I agree that especially the common simple use case results in more
lines of code, but it doesn't need to be as complicated as the example
in the beginning of the spec:

r = new FileReader;
r.readAsText(file);
r.onload = fileIsRead;

>> 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?

I'd like to hear implementation feedback here too. I'm especially
worried that implementations might not be able to use the urn scheme
due to limitations in the network stacks they are using.

But like Arun, I suspect that this feature is the most controversial
in the spec. Apple expressed concern about having a string represent a
handle to a resource, and when we talked to Microsoft they briefly
mentioned that they has concerns about this feature too, though I
don't know specifically what their concerns were.

I don't think we are assigning specific semantics to another scheme
that aren't already there. All we're saying is that urn:uuid
represents a specific chunk of data with a specific mimetype. This
seems like something that's already there with urn:uuid.

Arguably the status codes is something that urn:uuid doesn't already
have. Arun mentioned that we could possibly get rid of that.

/ Jonas

Received on Tuesday, 27 October 2009 21:35:38 UTC