Re: File API for Review
On Wed, Mar 27, 2013 at 8:18 PM, Arun Ranganathan a...@mozilla.com wrote: Done. http://dev.w3.org/2006/webapi/FileAPI/#NetworkError Awesome! -- http://annevankesteren.nl/
Re: File API for Review
On Mar 25, 2013, at 1:52 PM, Anne van Kesteren wrote: On Mon, Mar 25, 2013 at 5:45 PM, Arun Ranganathan aranganat...@mozilla.com wrote: So just to be clear, do you think we should remove 500-style responses altogether, and *completely defer* to network error, which essentially involves throwing on expired / revoked / invalid Blob URLs? I'm ok with that if so. Yeah, I would prefer if we used network error consistently throughout the platform for something went wrong with this URL rather than try to re-imagine a non-HTTP situation in terms of HTTP. Because it gives nicer to work with events and such out of the box and because it makes exposing more detailed information in the future easier. Done. http://dev.w3.org/2006/webapi/FileAPI/#NetworkError -- A*
Re: File API for Review
On Tue, Mar 19, 2013 at 5:57 PM, Arun Ranganathan a...@mozilla.com wrote: On Feb 13, 2013, at 11:37 AM, Anne van Kesteren wrote: 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. No, an HTTP status message is an actual thing and exposed via XMLHttpRequest. 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. I think it is. Network error is for whenever something goes wrong with the request. Otherwise this would give a load event rather than an error event. data: URLs use network errors too now: http://xhr.spec.whatwg.org/#data:-urls-and-http -- http://annevankesteren.nl/
Re: File API for Review
- Anne vK said: - On Tue, Mar 19, 2013 at 5:57 PM, Arun Ranganathan a...@mozilla.com wrote: On Feb 13, 2013, at 11:37 AM, Anne van Kesteren wrote: 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. No, an HTTP status message is an actual thing and exposed via XMLHttpRequest. You're right; this should be defined better in the File API. 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. I think it is. Network error is for whenever something goes wrong with the request. Otherwise this would give a load event rather than an error event. data: URLs use network errors too now: http://xhr.spec.whatwg.org/#data:-urls-and-http So just to be clear, do you think we should remove 500-style responses altogether, and *completely defer* to network error, which essentially involves throwing on expired / revoked / invalid Blob URLs? I'm ok with that if so. -- A*
Re: File API for Review
On Mon, Mar 25, 2013 at 5:45 PM, Arun Ranganathan aranganat...@mozilla.com wrote: So just to be clear, do you think we should remove 500-style responses altogether, and *completely defer* to network error, which essentially involves throwing on expired / revoked / invalid Blob URLs? I'm ok with that if so. Yeah, I would prefer if we used network error consistently throughout the platform for something went wrong with this URL rather than try to re-imagine a non-HTTP situation in terms of HTTP. Because it gives nicer to work with events and such out of the box and because it makes exposing more detailed information in the future easier. -- http://annevankesteren.nl/
Re: File API for Review
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*
Re: File API for Review
On Mar 8, 2013, at 8:28 AM, Henri Sivonen wrote: Additionally, I think http://www.w3.org/TR/FileAPI/#dfn-type should clarify that the browser must not use statistical methods to guess the charset parameter part of the type as part of determining the type. Firefox currently asks magic 8-ball, but the magic 8-ball is broken. AFAICT, WebKit does not guess, so I hope it's possible to remove the guessing from Firefox. (The guessing in Firefox relies on a big chunk of legacy code that's broken and shows no signs of ever getting fixed properly. The File API is currently the only thing in Firefox that exposes the mysterious behavior of said legacy code to the Web using the default settings of Firefox, so I'm hoping to remove the big chunk of legacy code instead of fixing it properly.) I think we can jettison Fx's use of magic 8-ball code with this update: http://dev.w3.org/2006/webapi/FileAPI/#dfn-type Additional spec'ing on when to ignore the string if provided incorrectly will follow. -- A*
Re: File API for Review
On Thu, Mar 7, 2013 at 9:09 PM, Arun Ranganathan aranganat...@mozilla.com wrote: I'm also not convinced that leaving what exactly to return in the HTTP scenario open to implementors is a good thing. We've been through such things before and learned that handwaving is bad. Lets just pick something. Just to be clear, are you referring to the 500 Error Condition for Blob URLs? If so, the only handwaving is about the text of the error message. I'm happy to tighten even this. So what I actually think we should do here is treat this as a network error. 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). Right now, the specification encourages user agents to get encoding from: 1. The encoding parameter supplied with the readAsText. 2. A byte order detection heuristic, if 1. is missing. 3. The charset component of Blob.type, if provided and if 1. and 2. yield no result. 4. Just use utf-8 if 1, 2, and 3 yield no result. Under the encoding spec., it returns failure if encoding isn't valid, and it returns failure if the BOM check fails. So should the spec. say something about throwing? So I think the decoding part of readAsText() should become something like this (assuming the argument to readAsText() is renamed to label): 1. Let /encoding/ be null. 2. If /label/ is given, set /encoding/ to the result of geting an encoding (Encoding Standard) for /label/. 3. If /encoding/ is failure, throw a TypeError. 4. If /encoding/ is null, get an encoding from Blob.type (not sure where this would be defined), and if that does not return failure, set /encoding/ to the result. 5. If /encoding/ is null, set /encoding/ to utf-8. 6. Decode (Encoding Standard) the /byte stream/ (or whatever this is called) using fallback encoding /encoding/. If throwing above is something implementations do not wish to do, we should change that to simply ignoring the argument if get an encoding returns failure. -- http://annevankesteren.nl/
Re: File API for Review
Additionally, I think http://www.w3.org/TR/FileAPI/#dfn-type should clarify that the browser must not use statistical methods to guess the charset parameter part of the type as part of determining the type. Firefox currently asks magic 8-ball, but the magic 8-ball is broken. AFAICT, WebKit does not guess, so I hope it's possible to remove the guessing from Firefox. (The guessing in Firefox relies on a big chunk of legacy code that's broken and shows no signs of ever getting fixed properly. The File API is currently the only thing in Firefox that exposes the mysterious behavior of said legacy code to the Web using the default settings of Firefox, so I'm hoping to remove the big chunk of legacy code instead of fixing it properly.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: File API for Review
Anne, On Wed, Feb 6, 2013 at 7:58 PM, Arun Ranganathan a...@mozilla.com wrote: 3. Progress events have been clarified. You're still using the old IDL syntax for event handlers. Fixed. I think we should rename URI to URL. That's what everyone is converging on. Fixed. I'm also not convinced that leaving what exactly to return in the HTTP scenario open to implementors is a good thing. We've been through such things before and learned that handwaving is bad. Lets just pick something. Just to be clear, are you referring to the 500 Error Condition for Blob URLs? If so, the only handwaving is about the text of the error message. I'm happy to tighten even this. Just like HTML, CSS, etc. this specification should defer to http://encoding.spec.whatwg.org/ for its encoding related requirements. I fully agree that what we've currently got, which favors a heuristic guessing model for encoding, and forces UTF-8 in a void, isn't sufficient. AND I agree that the encoding spec. is much more detailed. But what exactly does deferring to it entail? Right now, the specification encourages user agents to get encoding from: 1. The encoding parameter supplied with the readAsText. 2. A byte order detection heuristic, if 1. is missing. 3. The charset component of Blob.type, if provided and if 1. and 2. yield no result. 4. Just use utf-8 if 1, 2, and 3 yield no result. Under the encoding spec., it returns failure if encoding isn't valid, and it returns failure if the BOM check fails. So should the spec. say something about throwing? 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. OK. -- A*
Re: File API for Review
On Feb 6, 2013 8:59 PM, Arun Ranganathan a...@mozilla.com wrote: Greetings WebApps WG! Review on the File API is encouraged: http://dev.w3.org/2006/webapi/FileAPI/ A few substantial changes that might need particular attention before we initiate a call for LCWD or something comparably official: 1. autoRevoke behavior of Blob URIs has changed. Previous drafts made the autoRevoke behavior on by default (by consensus), but didn't harness revocation to a suitable and unambiguous scope. Thanks to a fix to HTML[1] we can leverage the global script clean-up jobs list, to which we add revocation of Blob URIs. Blob URIs are thus either scoped to the next time global script clean-up jobs are processed (by default), OR when document unloading steps are processed if the developer opts out of the default but never pairs it with a call to URL.revokeObjectURL, OR when URL.revokeObjectURL is called. In particular, this behavior defers from shipping implementations such as IE10. This is possibly the biggest change: http://dev.w3.org/2006/webapi/FileAPI/#lifeTime http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking I would definitely like to get input from other implementers if this is a change that you are willing to do? 2. An utility to smooth line ending variations (Unix vs. Windows) has been added, but is an orphan interface currently. Nobody's fussed over this, and it might not be a problem at all, but I'd like to draw your attention to it :) While currently only relevant for DOMString arguments to the Blob constructor, we might work with the utility to add other arguments (including ArrayBufferViews, etc.). http://dev.w3.org/2006/webapi/FileAPI/#convenienceAPI Given how recent this addition is, and given that it's fairly easy to implement in JS directly, I think we should drip this feature from v1 and reconsider for a later version. As it stands now it doesn't really seem to add a lot of value. / Jonas
Re: File API for Review
On Wed, Feb 13, 2013 at 11:14 AM, Jonas Sicking jo...@sicking.cc wrote: On Feb 6, 2013 8:59 PM, Arun Ranganathan a...@mozilla.com wrote: http://dev.w3.org/2006/webapi/FileAPI/#convenienceAPI Given how recent this addition is, and given that it's fairly easy to implement in JS directly, I think we should drip this feature from v1 and reconsider for a later version. As it stands now it doesn't really seem to add a lot of value. And if we keep it, we should not have it on the global scope, imo. -- http://annevankesteren.nl/
Re: File API for Review
On Wed, Feb 6, 2013 at 7:58 PM, Arun Ranganathan a...@mozilla.com wrote: 3. Progress events have been clarified. You're still using the old IDL syntax for event handlers. Specification bugs still exist I think we should rename URI to URL. That's what everyone is converging on. I'm also not convinced that leaving what exactly to return in the HTTP scenario open to implementors is a good thing. We've been through such things before and learned that handwaving is bad. Lets just pick something. Just like HTML, CSS, etc. this specification should defer to http://encoding.spec.whatwg.org/ for its encoding related requirements. 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. -- http://annevankesteren.nl/
