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*
