Re: Alarm API Feedback

Hi,

Based on Jonas' feedback, I would simplify and propose to document only the
following errors:

*- getAll()*
  * AlarmRequest.error will be set to *UnknownError* in any error case.

*- add()*
  * AlarmRequest.error will be set to *InvalidStateError* if the alarm's
date is set in the past, or *UnknownError* in any other error case.

[ As Jonas mentioned, we could throw an *InvalidStateError* exception
synchronously. However, my worry is that this may be "racy" in case the
implementation needs to asynchronously interact with a backend. What I mean
is that the alarm date/time may be valid when add() is called but may in
theory become invalid by the time it is asynchronously processed by the
backend. Therefore, I think it would be safer to return the *
InvalidStateError* asynchronously as well. ]

*- remove()*
  * AlarmRequest.error will be set to *UnknownError* in any error case.
  * We document that AlarmRequest.result will be set to *True* if the alarm
was successfully removed and *False* otherwise.

Note that I included I/O errors in *UnknownError*. I believe this is the
approach that is chosen by the IndexedDB API as well. My understanding is
that DOM4 does not specify a specific error type for I/O errors either.
Of course, we can still decide to add such error type in Alarm API but I'm
not sure this is needed.

Kr,
-- 
Christophe Dumez, PhD
Linux Software Engineer
Intel Finland Oy - Open Source Technology Center