The LCWD of File API is http://www.w3.org/TR/FileAPI/

LC comment period is till October 24 2013 -- comments strongly encouraged!

-- A*

On Aug 16, 2013, at 8:35 AM, Arthur Barstow wrote:

> Arun proposed (see below) WebApps publish a Last Call Working Draft of File 
> API and this is a Call for Consensus to do so, using the following ED as the 
> basis:
> 
> <http://dev.w3.org/2006/webapi/FileAPI/>
> 
> This CfC satisfies the group's requirement to "record the group's decision to 
> request advancement" for this LCWD. Note the Process Document states the 
> following regarding the significance/meaning of a LCWD:
> 
> [[
> http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
> 
> Purpose: A Working Group's Last Call announcement is a signal that:
> 
> * the Working Group believes that it has satisfied its relevant technical 
> requirements (e.g., of the charter or requirements document) in the Working 
> Draft;
> 
> * the Working Group believes that it has satisfied significant dependencies 
> with other groups;
> 
> * other groups SHOULD review the document to confirm that these dependencies 
> have been satisfied. In general, a Last Call announcement is also a signal 
> that the Working Group is planning to advance the technical report to later 
> maturity levels.
> ]]
> 
> The proposed review period for this LC is 4 weeks.
> 
> There are two open [Bugs] for this spec.
> 
> If you have any comments or concerns about this CfC, please send them to 
> [email protected] by August 23 at the latest. Positive response is 
> preferred and encouraged and silence will be considered as agreement with the 
> proposal.
> 
> -Thanks, AB
> 
> [Bugs] <http://tinyurl.com/Bugs-FileAPI>
> 
> 
> -------- Original Message --------
> Subject:      File* Specifications | Status and some Promises
> Resent-Date:  Thu, 15 Aug 2013 17:50:25 +0000
> Resent-From:  <[email protected]>
> Date:         Thu, 15 Aug 2013 13:49:38 -0400
> From:         ext Arun Ranganathan <[email protected]>
> To:   Web Applications Working Group WG <[email protected]>
> 
> 
> 
> Greetings WG,
> 
> There are three moving proposals in the File* arena, and I thought I'd 
> catpure what these are and what the status of these are.
> 
> 1. The File API, currently updated as editor's draft at 
> http://dev.w3.org/2006/webapi/FileAPI/
> 
> Review strongly encouraged :)  Notable fixes are:
> 
> i. A File constructor has been added, which has been a longstanding request.
> ii. A new static method on URL called URL.createAndRevoke has been added that 
> gets defaults right, and does away with autoRevoke, which nobody implemented 
> for URL.createObjectURL.
> iii. A Blob URL Store and a Revocation List, useful for URL Fetch (see 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765).
> 
> This draft should be ready for LC and should be considered the File API v1.
> 
> 2. Re-writing File APi to be Promises based, which should be considered a v2. 
>  The biggest departure from the current state of technology here would really 
> be that we can have Promises right off the Blob itself, which is zeitgeist 
> thinking about these things (and admittedly makes life easier than an 
> XHR-inspired FileReader, which will be made legacy).  The best stab at a 
> strawperson was this one by Jonas:
> 
> http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0727.html
> 
> But Stream itself temporarily lives here without too much implementation 
> backbone: https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
> 
> I think we *should* have a Promises-based File API off of Blob, but I'm not 
> totally sure about the Stream API as it is currently written; I'm amenable to 
> editing the File API v2 portion, modulo our proposal for Stream.
> 
> 3. Then there's the FileSystem API, currently discussed here: 
> http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0379.html
> 
> This was the upshot of discussions on this listserv, as well as internally at 
> Mozilla.  I'm amenable to editing this, which is separate but related to 1. 
> and 2.
> 
> -- A*
> 
> 
> 
> 
> 
> 
> 
> 


Reply via email to