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*

Received on Saturday, 1 October 2011 01:47:30 UTC