[File API] Issue 182 about OperationNowAllowed

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 Thursday, 29 September 2011 22:28:48 UTC