Re: Alarm API Feedback

On Fri, Jan 18, 2013 at 2:59 AM, Dumez, Christophe
<christophe.dumez@intel.com> wrote:
> - 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. ]

Agreed. I'm also worried about the racyness of throwing depending of
the time of day.

Another way to handle alarms scheduled in the past is to simply accept
them and fire the alarm immediately (but of course asynchronously).

I don't have a strong opinion at this time and it's definitely
something we can change later. But there is a certain racyness
involved with making it an error.

> - 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.

Sounds good.

> 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.

Yup. I bet this is something that will come up in several situations.
I don't have a strong opinion but being consistent across specs is
always nice.

/ Jonas

Received on Friday, 18 January 2013 21:23:59 UTC