W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: File API for Review

From: Arun Ranganathan <arun@mozilla.com>
Date: Tue, 19 Mar 2013 13:57:54 -0400
Cc: Web Applications Working Group WG <public-webapps@w3.org>
Message-Id: <10D50CC7-43E4-4EDA-BE84-3532166B9017@mozilla.com>
To: Anne van Kesteren <annevk@annevk.nl>

On Feb 13, 2013, at 11:37 AM, Anne van Kesteren wrote:

> 
>> Specification bugs still exist
> 
> I think we should rename URI to URL. That's what everyone is converging on.
> 


Done.


> I'm also not convinced that leaving what exactly to return in the HTTP
> scenario open to implementors is a good thing. 


(There isn't an HTTP scenario here).


> So what I actually think we should do here is treat this as a networkerror. XMLHttpRequest already knows about that concept and every other end point also deals with network errors in a predictable and standardized way. Phrasing such as "Act as if a network error occurred" seems sufficient for now (until Fetch provides hooks).


We're not actually leaving what exactly to return open to implementors.  They *must* return a 500.  They *may* additionally provide a message, which is akin to console messages.  Also, networkerror isn't really strongly defined; XMLHttpRequest uses this to throw on network errors (NetworkError), and there isn't currently a Fetch in HTML that leverages networkerrors.  This is not obviously reusable here in the blob: URL context.

The spec. doesn't need to mention anything about throwing -- we're returning a 500 if a blob: URL cannot be dereferenced, not throwing an exception.  This is specific, and not left to implementations to determine.


> Just like HTML, CSS, etc. this specification should defer to
> http://encoding.spec.whatwg.org/ for its encoding related
> requirements.


Done (and uses most of your proposed changes): http://dev.w3.org/2006/webapi/FileAPI/#encoding-determination


> 
> I don't think we should throw for limitations on URL length. We always
> leave undefined lengths unaddressed in specifications, including with
> regards to how to handle them.
> 


Done.

-- A*
Received on Tuesday, 19 March 2013 17:58:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:58 GMT