Re: [File API] Latest Editor's Draft | Call for Review

[Jonas Sicking]

For FileReader.abort(), we should only fire "abort" and "loadend"
events if there is a load currently in progress. If no load is in
progress then no events should be fired.

Basically the invariant we want to enforce is that for each
"loadstart" event there is one and exactly one "loadend" event as well
as one of "error", "load" or "abort". That makes it easier for people
to build state machines which react to the various events.

One way to do this would be to merge step 1 and step 3 into:

1. If readyState = EMPTY or readyState = DONE, set result to null and
terminate the overall set of steps without doing anything else.

/ Jonas

On Thu, Aug 11, 2011 at 12:43 PM, Arun Ranganathan  wrote:
> Greetings WebApps WG,
>
> The latest editor's draft of the File API can be found here:
>
> http://dev.w3.org/2006/webapi/FileAPI/
>
> Changes are based on feedback on this listserv, as well as the URI listserv
> (e.g. [1][2][3]).
>
> Chrome team: some of the feedback is to more rigorously define the
> opaqueString production in Blob URIs.  Currently, you generate Blob URIs
> that look like this:
>
> blob:http://localhost/c745ef73-ece9-46da-8f66-ebes574789b1 [4]
>
> I've included language that allows use of this kind, but some review about
> what is NOT allowed would be appreciated.
>
> -- A*
>
> [1] http://lists.w3.org/Archives/Public/uri/2011May/0004.html
> [2] http://lists.w3.org/Archives/Public/uri/2011May/0002.html
> [3] http://lists.w3.org/Archives/Public/uri/2011May/0006.html
> [4]
> http://www.html5rocks.com/en/tutorials/workers/basics/#toc-inlineworkers-bloburis
>
>

Re: [File API] Latest Editor's Draft | Call for Review

[Jian Li]

On Thu, Aug 11, 2011 at 12:43 PM, Arun Ranganathan  wrote:

> Greetings WebApps WG,
>
> The latest editor's draft of the File API can be found here:
>
> http://dev.w3.org/2006/webapi/**FileAPI/
>
> Changes are based on feedback on this listserv, as well as the URI listserv
> (e.g. [1][2][3]).
>
> Chrome team: some of the feedback is to more rigorously define the
> opaqueString production in Blob URIs.  Currently, you generate Blob URIs
> that look like this:
>
> blob:http://localhost/**c745ef73-ece9-46da-8f66-**ebes574789b1[4]
>

For chromium, we're going to escape those reserved characters that could
appear in the opaqueString.


>
> I've included language that allows use of this kind, but some review about
> what is NOT allowed would be appreciated.
>
> -- A*
>
> [1] 
> http://lists.w3.org/Archives/**Public/uri/2011May/0004.html
> [2] 
> http://lists.w3.org/Archives/**Public/uri/2011May/0002.html
> [3] 
> http://lists.w3.org/Archives/**Public/uri/2011May/0006.html
> [4] http://www.html5rocks.com/en/**tutorials/workers/basics/#toc-**
> inlineworkers-bloburis
>
>

[File API] Latest Editor's Draft | Call for Review

[Arun Ranganathan]

Greetings WebApps WG,

The latest editor's draft of the File API can be found here:

http://dev.w3.org/2006/webapi/FileAPI/

Changes are based on feedback on this listserv, as well as the URI 
listserv (e.g. [1][2][3]).


Chrome team: some of the feedback is to more rigorously define the 
opaqueString production in Blob URIs.  Currently, you generate Blob URIs 
that look like this:


blob:http://localhost/c745ef73-ece9-46da-8f66-ebes574789b1 [4]

I've included language that allows use of this kind, but some review 
about what is NOT allowed would be appreciated.


-- A*

[1] http://lists.w3.org/Archives/Public/uri/2011May/0004.html
[2] http://lists.w3.org/Archives/Public/uri/2011May/0002.html
[3] http://lists.w3.org/Archives/Public/uri/2011May/0006.html
[4] 
http://www.html5rocks.com/en/tutorials/workers/basics/#toc-inlineworkers-bloburis