Re: [File API] Issue 182 about OperationNotAllowed
On Tue, 04 Oct 2011 00:59:18 +0200, Jonas Sicking jo...@sicking.cc wrote: Yup. I do wonder if we should introduce a DOMError class which can be reused in various cases which need APIs like this. IndexedDB could also use it and I seem to recall that HTML5 does too. I could certainly introduce a DOMError interface with a name and a message attribute. For the APIs that want to provide the same information asynchronous as they do synchronous through exceptions that makes sense. Would that work? OK. So it's when we need new exception codes, names, and types that the confusion with this model sets in. While we can add to DOMException in a decentralized way, do the editors of DOM4 intend to add the new exceptions to DOMException? I'll leave this one for Anne. I personally don't care where the new strings are defined. Anne seemed to prefer to do it in the DOM4 (aka DOM Core) spec, but I don't think we want to block on that happening. The idea I had was that everyone can introduce new strings. After all, as far as normative statements in a specification go, you need nothing more than this line: # Throw a SyntaxError exception On top of that my plan was that whenever a specification author introduces a string there that is not yet in DOM4 they send a request for it to be included and one of the DOM4 editors will add the exception and a brief description to the overview table. Having it in the overview table will help other editors choosing the appropriate string. Apart from making sure certain strings get their legacy code value assigned (already in the table) the table would be completely non-normative however and no specification introducing strings not yet in the table is blocked by it updating. It's just an overview. -- Anne van Kesteren http://annevankesteren.nl/
Re: [File API] Issue 182 about OperationNotAllowed
On Mon, Oct 3, 2011 at 11:54 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 04 Oct 2011 00:59:18 +0200, Jonas Sicking jo...@sicking.cc wrote: Yup. I do wonder if we should introduce a DOMError class which can be reused in various cases which need APIs like this. IndexedDB could also use it and I seem to recall that HTML5 does too. I could certainly introduce a DOMError interface with a name and a message attribute. For the APIs that want to provide the same information asynchronous as they do synchronous through exceptions that makes sense. Would that work? Yup, that'd work. Another option which just occurred to me is to actually use DOMException objects. The ECMAScript error objects don't actually have anything exception specific about them. DOMException only does so by name of the interface. Either way is fine with me. / Jonas
Re: [File API] Issue 182 about OperationNotAllowed
On 10/4/11 2:54 AM, Anne van Kesteren wrote: On Tue, 04 Oct 2011 00:59:18 +0200, Jonas Sicking jo...@sicking.cc wrote: Yup. I do wonder if we should introduce a DOMError class which can be reused in various cases which need APIs like this. IndexedDB could also use it and I seem to recall that HTML5 does too. I could certainly introduce a DOMError interface with a name and a message attribute. For the APIs that want to provide the same information asynchronous as they do synchronous through exceptions that makes sense. Would that work? Works for me :-) Happy to work with you to introduce DOMError in DOM4; seems pretty straightforward and as soon as it is in, I'll refer to it. OK, it's time to bid a fond farewell to FileException and FileError if that's the way we're doing exceptions from this day forward. OK. So it's when we need new exception codes, names, and types that the confusion with this model sets in. While we can add to DOMException in a decentralized way, do the editors of DOM4 intend to add the new exceptions to DOMException? I'll leave this one for Anne. I personally don't care where the new strings are defined. Anne seemed to prefer to do it in the DOM4 (aka DOM Core) spec, but I don't think we want to block on that happening. The idea I had was that everyone can introduce new strings. After all, as far as normative statements in a specification go, you need nothing more than this line: # Throw a SyntaxError exception On top of that my plan was that whenever a specification author introduces a string there that is not yet in DOM4 they send a request for it to be included and one of the DOM4 editors will add the exception and a brief description to the overview table. Having it in the overview table will help other editors choosing the appropriate string. Apart from making sure certain strings get their legacy code value assigned (already in the table) the table would be completely non-normative however and no specification introducing strings not yet in the table is blocked by it updating. It's just an overview. OK, this works for me. -- A*
Re: [File API] Issue 182 about OperationNotAllowed
On 9/30/11 9:46 PM, Adrian Bateman wrote: Hi Arun, Thanks for the follow-up - you beat me to it. We've been reviewing this in the context of the other specs and, as Israel outlined for IndexedDB, we're happy with the new WebIDL approach. I think we should go ahead and migrate the File API exceptions to this new model and use ISSUE-182 to drive that change. Adrian, That's great :) Just to clarify from a File API perspective, are you ok with an OperationNotAllowed exception, *or* are you advocating reuse of DOMException with OperationNotAllowed like how IndexedDB is doing? I'm unclear whether I should change what is in the editor's draft now. A somewhat affiliated question is whether there should be a message attribute in our FileException and OperationNotAllowed exceptions (and in FileError). -- A*
Re: [File API] Issue 182 about OperationNotAllowed
On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathan a...@mozilla.com wrote: On 9/30/11 9:46 PM, Adrian Bateman wrote: Hi Arun, Thanks for the follow-up - you beat me to it. We've been reviewing this in the context of the other specs and, as Israel outlined for IndexedDB, we're happy with the new WebIDL approach. I think we should go ahead and migrate the File API exceptions to this new model and use ISSUE-182 to drive that change. Adrian, That's great :) Just to clarify from a File API perspective, are you ok with an OperationNotAllowed exception, *or* are you advocating reuse of DOMException with OperationNotAllowed like how IndexedDB is doing? I'm unclear whether I should change what is in the editor's draft now. A somewhat affiliated question is whether there should be a message attribute in our FileException and OperationNotAllowed exceptions (and in FileError). Here are my feelings: 1. Get rid of FileError/OperationNotAllowedException completely. All exceptions we throw should be DOMExceptions. 2. We should try to reuse as many exceptions as we can from the DOM4 spec. That means that in the places where we throw OperationNotAllowedException we should throw a DOMException with .name=InvalidStateError. For SECURITY_ERR we'll want to use DOMException with .name=SecurityError For ABORT_ERR we'll want to use DOMException with .name=AbortError For NOT_READABLE_ERR I think we'll want to mint a new error. Something like DOMException with .name=IOError or some such? For ENCODING_ERR, I think we'll want to mint a new error. DOMException with .name=CharsetEncodingError maybe? In the cases where we reuse existing errors, the .code should be set to the code that the DOM4 spec defines. But I think if we use the correct vocabulary, the DOM4 spec will take care of that. cc'ing Anne who helped out with this for IndexedDB recently. / Jonas
Re: [File API] Issue 182 about OperationNotAllowed
On 10/3/11 4:59 PM, Jonas Sicking wrote: On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathana...@mozilla.com wrote: On 9/30/11 9:46 PM, Adrian Bateman wrote: Hi Arun, Thanks for the follow-up - you beat me to it. We've been reviewing this in the context of the other specs and, as Israel outlined for IndexedDB, we're happy with the new WebIDL approach. I think we should go ahead and migrate the File API exceptions to this new model and use ISSUE-182 to drive that change. Adrian, That's great :) Just to clarify from a File API perspective, are you ok with an OperationNotAllowed exception, *or* are you advocating reuse of DOMException with OperationNotAllowed like how IndexedDB is doing? I'm unclear whether I should change what is in the editor's draft now. A somewhat affiliated question is whether there should be a message attribute in our FileException and OperationNotAllowed exceptions (and in FileError). Here are my feelings: 1. Get rid of FileError/OperationNotAllowedException completely. All exceptions we throw should be DOMExceptions. 2. We should try to reuse as many exceptions as we can from the DOM4 spec. Eeep! :) This is a big-ish change, but I'm amenable to it, especially to stay consistent with what IndexedDB is doing (and to be consistent with HTML/XHR2, etc.). But to be clear, above you mean: 1. Get rid of FileException and OperationNotAllowedException completely, but you probably do NOT mean get rid of FileError. We'll want to keep FileError since it's an asynchronously handled error object in onerror, but we'll reuse whatever we reuse from DOMException, if it makes sense to do so. Honestly, implementations are not consistent with respect to what they throw today with respect to FileException and read-affiliated exceptions, so if it helps get us some consistency by channeling things through DOM4 (and WebIDL), I'm okay with it, short term pain of changing the spec. notwithstanding. That means that in the places where we throw OperationNotAllowedException we should throw a DOMException with .name=InvalidStateError. OK. For SECURITY_ERR we'll want to use DOMException with .name=SecurityError OK. For ABORT_ERR we'll want to use DOMException with .name=AbortError We don't actually throw an ABORT_ERR, so one thing that's attractive about making this change is that we'll eliminate redundant codes in objects we don't actually use. For NOT_READABLE_ERR I think we'll want to mint a new error. Something like DOMException with .name=IOError or some such? OK. So it's when we need new exception codes, names, and types that the confusion with this model sets in. While we can add to DOMException in a decentralized way, do the editors of DOM4 intend to add the new exceptions to DOMException? For ENCODING_ERR, I think we'll want to mint a new error. DOMException with .name=CharsetEncodingError maybe? OK (same question). In the cases where we reuse existing errors, the .code should be set to the code that the DOM4 spec defines. But I think if we use the correct vocabulary, the DOM4 spec will take care of that. cc'ing Anne who helped out with this for IndexedDB recently. (Commentary from Anne welcome). -- A*
Re: [File API] Issue 182 about OperationNotAllowed
On 10/3/11 6:59 PM, Jonas Sicking wrote: On Mon, Oct 3, 2011 at 3:35 PM, Arun Ranganathana...@mozilla.com wrote: On 10/3/11 4:59 PM, Jonas Sicking wrote: On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathana...@mozilla.com wrote: On 9/30/11 9:46 PM, Adrian Bateman wrote: Hi Arun, Thanks for the follow-up - you beat me to it. We've been reviewing this in the context of the other specs and, as Israel outlined for IndexedDB, we're happy with the new WebIDL approach. I think we should go ahead and migrate the File API exceptions to this new model and use ISSUE-182 to drive that change. Adrian, That's great :) Just to clarify from a File API perspective, are you ok with an OperationNotAllowed exception, *or* are you advocating reuse of DOMException with OperationNotAllowed like how IndexedDB is doing? I'm unclear whether I should change what is in the editor's draft now. A somewhat affiliated question is whether there should be a message attribute in our FileException and OperationNotAllowed exceptions (and in FileError). Here are my feelings: 1. Get rid of FileError/OperationNotAllowedException completely. All exceptions we throw should be DOMExceptions. 2. We should try to reuse as many exceptions as we can from the DOM4 spec. Eeep! :) This is a big-ish change, but I'm amenable to it, especially to stay consistent with what IndexedDB is doing (and to be consistent with HTML/XHR2, etc.). But to be clear, above you mean: 1. Get rid of FileException and OperationNotAllowedException completely, but you probably do NOT mean get rid of FileError. We'll want to keep FileError since it's an asynchronously handled error object in onerror, but we'll reuse whatever we reuse from DOMException, if it makes sense to do so. Yup. I do wonder if we should introduce a DOMError class which can be reused in various cases which need APIs like this. IndexedDB could also use it and I seem to recall that HTML5 does too. I'm happy with a DOMError class that can be reused, but I'd rather not block on it unless it can be done in short order. It might live in HTML, although currently the onerror handler for script errors (if a Function) has three arguments and doesn't seem to need a dedicated error object. Earlier, when I wanted to keep constants in sync with DOMException, there was some resistance. If we maintain a FileError object, it may now actually make sense to replicate some of the constants from DOMException, since there is no longer a FileException. Or, we can follow how HTML handles script errors (and forego a dedicated error object). Cc'ing Hixie as well to comment on what HTML might need. OK. So it's when we need new exception codes, names, and types that the confusion with this model sets in. While we can add to DOMException in a decentralized way, do the editors of DOM4 intend to add the new exceptions to DOMException? I'll leave this one for Anne. I personally don't care where the new strings are defined. Anne seemed to prefer to do it in the DOM4 (aka DOM Core) spec, but I don't think we want to block on that happening. I don't think we should block on DOM4 either. -- A*
Re: [File API] Issue 182 about OperationNotAllowed
On Mon, 3 Oct 2011, Arun Ranganathan wrote: Cc'ing Hixie as well to comment on what HTML might need. As far as I'm concerned, what HTML has now is fine (DOMException based on how DOM Core defines it). I'll leave this one for Anne. I personally don't care where the new strings are defined. Anne seemed to prefer to do it in the DOM4 (aka DOM Core) spec, but I don't think we want to block on that happening. I don't think we should block on DOM4 either. Isn't it already done? It's what HTML is using... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [File API] Issue 182 about OperationNotAllowed
On Mon, Oct 3, 2011 at 4:26 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 3 Oct 2011, Arun Ranganathan wrote: Cc'ing Hixie as well to comment on what HTML might need. As far as I'm concerned, what HTML has now is fine (DOMException based on how DOM Core defines it). I'll leave this one for Anne. I personally don't care where the new strings are defined. Anne seemed to prefer to do it in the DOM4 (aka DOM Core) spec, but I don't think we want to block on that happening. I don't think we should block on DOM4 either. Isn't it already done? It's what HTML is using... I looked at how for example WebSockets and EventSource exposes error information. I would have thought in both cases that it would have been done as a property on the websocket/eventsource object itself. However I couldn't find any such property, and since the error events fired by both specifications are simple Events it doesn't appear as if the information is exposed on the event object either. Do neither of these specifications make error information available? / Jonas
Re: [File API] Issue 182 about OperationNotAllowed
On Mon, Oct 3, 2011 at 3:35 PM, Arun Ranganathan a...@mozilla.com wrote: On 10/3/11 4:59 PM, Jonas Sicking wrote: On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathana...@mozilla.com wrote: On 9/30/11 9:46 PM, Adrian Bateman wrote: Hi Arun, Thanks for the follow-up - you beat me to it. We've been reviewing this in the context of the other specs and, as Israel outlined for IndexedDB, we're happy with the new WebIDL approach. I think we should go ahead and migrate the File API exceptions to this new model and use ISSUE-182 to drive that change. Adrian, That's great :) Just to clarify from a File API perspective, are you ok with an OperationNotAllowed exception, *or* are you advocating reuse of DOMException with OperationNotAllowed like how IndexedDB is doing? I'm unclear whether I should change what is in the editor's draft now. A somewhat affiliated question is whether there should be a message attribute in our FileException and OperationNotAllowed exceptions (and in FileError). Here are my feelings: 1. Get rid of FileError/OperationNotAllowedException completely. All exceptions we throw should be DOMExceptions. 2. We should try to reuse as many exceptions as we can from the DOM4 spec. Eeep! :) This is a big-ish change, but I'm amenable to it, especially to stay consistent with what IndexedDB is doing (and to be consistent with HTML/XHR2, etc.). But to be clear, above you mean: 1. Get rid of FileException and OperationNotAllowedException completely, but you probably do NOT mean get rid of FileError. We'll want to keep FileError since it's an asynchronously handled error object in onerror, but we'll reuse whatever we reuse from DOMException, if it makes sense to do so. Yup. I do wonder if we should introduce a DOMError class which can be reused in various cases which need APIs like this. IndexedDB could also use it and I seem to recall that HTML5 does too. For NOT_READABLE_ERR I think we'll want to mint a new error. Something like DOMException with .name=IOError or some such? OK. So it's when we need new exception codes, names, and types that the confusion with this model sets in. While we can add to DOMException in a decentralized way, do the editors of DOM4 intend to add the new exceptions to DOMException? I'll leave this one for Anne. I personally don't care where the new strings are defined. Anne seemed to prefer to do it in the DOM4 (aka DOM Core) spec, but I don't think we want to block on that happening. / Jonas
Re: [File API] Issue 182 about OperationNotAllowed
On Mon, 3 Oct 2011, Jonas Sicking wrote: I looked at how for example WebSockets and EventSource exposes error information. I would have thought in both cases that it would have been done as a property on the websocket/eventsource object itself. However I couldn't find any such property, and since the error events fired by both specifications are simple Events it doesn't appear as if the information is exposed on the event object either. Do neither of these specifications make error information available? Web Sockets exposes error information in the 'close' handler, if that counts. That's unrelated to exceptions, though. It uses a custom event interface type. Generally speaking I try to avoid exposing too much error information to script (as opposed to the developer console) because it can often lead to security problems (e.g. leaking information about intranet topology). HTMLMediaElement exposes error state on a .error attribute that returns a MediaError object (or null), which itself just has a single .code attribute currently, that being a value from 1 to 4 (corresponding to some defined constants). At some point in the future it may be extended to provide more information in the object, but there are no immediate plans to do so. In any case, this is also not an exception, and no attempt is made to keep these codes synced with the exception codes. All exception handling in the HTML spec uses the DOM Core behaviour. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [File API] Issue 182 about OperationNotAllowed
On Mon, Oct 3, 2011 at 6:00 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 3 Oct 2011, Jonas Sicking wrote: I looked at how for example WebSockets and EventSource exposes error information. I would have thought in both cases that it would have been done as a property on the websocket/eventsource object itself. However I couldn't find any such property, and since the error events fired by both specifications are simple Events it doesn't appear as if the information is exposed on the event object either. Do neither of these specifications make error information available? Web Sockets exposes error information in the 'close' handler, if that counts. That's unrelated to exceptions, though. It uses a custom event interface type. Generally speaking I try to avoid exposing too much error information to script (as opposed to the developer console) because it can often lead to security problems (e.g. leaking information about intranet topology). HTMLMediaElement exposes error state on a .error attribute that returns a MediaError object (or null), which itself just has a single .code attribute currently, that being a value from 1 to 4 (corresponding to some defined constants). At some point in the future it may be extended to provide more information in the object, but there are no immediate plans to do so. In any case, this is also not an exception, and no attempt is made to keep these codes synced with the exception codes. All exception handling in the HTML spec uses the DOM Core behaviour. I agree that exposing error information can be a problem. However it seems like this is safe enough in specs where we use CORS or similar explicit-opt-in protocols. In those cases I think it's generally a good idea to expose error info to pages. So MediaError is exactly the type of thing that I'm talking about that we might want to move into the DOM4 spec. We have the same thing in the File API spec. The FileError interface is just a plain object with a single .code property. We're planning on moving that to expose a .name property instead which will contain the same strings as DOMException.name. I'm thinking we should do the same thing for IndexedDB too. So having a central DOMError interface which we can reuse for all places which expose asynchronous errors would be helpful. If specifications want to add more information than what's defined by DOM4, they can always extend the interface. / Jonas
Re: [File API] Issue 182 about OperationNotAllowed
On Mon, 3 Oct 2011, Jonas Sicking wrote: So MediaError is exactly the type of thing that I'm talking about that we might want to move into the DOM4 spec. We have the same thing in the File API spec. The FileError interface is just a plain object with a single .code property. We're planning on moving that to expose a .name property instead which will contain the same strings as DOMException.name. I'm thinking we should do the same thing for IndexedDB too. So having a central DOMError interface which we can reuse for all places which expose asynchronous errors would be helpful. If specifications want to add more information than what's defined by DOM4, they can always extend the interface. Oh, I don't think I'd use a central error interface for HTMLMediaElement.error. I don't really see much value to it. Going forward I see us putting all kinds of media-specific stuff in there like the name of the codec, the frame at which the error occurred, or other such things. Those wouldn't make sense in a FileError equivalent. In a FileError I would imagine seeing such things as a reference to the relevant File object, or a byte offset into where the read error occurred, or whatnot. We could have them all inherit from a common Error interface, but honestly that doesn't get us much. I agree that we should try to be consistent going forward. It's not a huge issue though. I don't mind adding a name attribute to MediaError at some point if that's the way other such interfaces go. I don't expect most authors to ever interact with this part of the API so it's not a high priority. (First we have to add video metrics, for instance. In some manner that doesn't lead to helping fingerprinters...) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: [File API] Issue 182 about OperationNotAllowed
Hi Arun, Thanks for the follow-up - you beat me to it. We've been reviewing this in the context of the other specs and, as Israel outlined for IndexedDB, we're happy with the new WebIDL approach. I think we should go ahead and migrate the File API exceptions to this new model and use ISSUE-182 to drive that change. Cheers, Adrian. On Thursday, September 29, 2011 3:28 PM, Arun Ranganathan wrote: On 6/6/11 4:36 PM, Adrian Bateman wrote: On Monday, June 06, 2011 5:56 AM, Arthur Barstow wrote: Hi Arun, Jonas, All, The last publication of the File API spec [ED] was last October so it would be good to publish a new Working Draft in w3.org/TR/. Since Tracker shows 0 bugs for the spec [Tracker] and the ED does not appear to identify any open issues, does the spec meet the Last Call Working Draft requirements (as, indicated in previous CfCs for LCWD such as [CfC-LCWD])? If not, what is the schedule and plan to get this spec LC ready? I've added two new issues to tracker [1,2] based on our review of the latest changes to the spec. I think we're getting close to Last Call and it would be good to set a pre-Last Call schedule to tease out any remaining issues. Cheers, Adrian. [1] http://www.w3.org/2008/webapps/track/issues/181 [2] http://www.w3.org/2008/webapps/track/issues/182 Greetings Adrian, I've closed Issue 181, which pertains to a name attribute on exception objects that is now redundant, thanks to WebIDL's evolution for exception interfaces. But I'm not readily able to close Issue 182, which pertains to the OperationNotAllowed exception, which we've added to the specification for reuse across the platform. You cite IndexedDB's reuse of existing exceptions to throw a NOT_ALLOWED_ERR but OperationNowAllowed is for API issues particularly, whereas the other reuses may have more to do with the exception class (within databases, etc.). I updated the comments in Issue 182, in case you want to have the discussion there. But there's a need for a distinct exception that is raised when an operation such as API call order is simply not allowed. To reuse FileException is to tie an API call order question to exceptions typically associated with the underlying file system; that's not what we're trying to do here. The idea was to: 1. Use FileException and FileError uniquely for file errors and 2. To make a clean break with DOMException, which has an untenable list of error codes. Separately, Robin Berjon counsels us NOT to use numerical codes. But I'm not sure what to supplant existing codes with, even if there is overlap. -- A*
