- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 8 May 2013 12:29:08 -0700
- To: Jake Verbaten <raynos2@gmail.com>
- Cc: Marcos Caceres <w3c@marcosc.com>, public-script-coord <public-script-coord@w3.org>
On Wed, May 8, 2013 at 12:14 PM, Jake Verbaten <raynos2@gmail.com> wrote:
>> which means that it's impossible
>> to know what the alarm id is for cancelling until it's too late to
>> cancel it.
>
> I've actually interpreted the API wrongly. add returns once the device
> succesfully tells you that the alarm has been registered.
>
> You actually listen to the actual alarm going of by using
> `navigator.setMessageHandler("alarm", onAlarmFired);` which I missed on my
> first scan.
Oh, I see! Yes, that's very unclear, though this is partially due to
my ignorance of "system messages". It negates several of my issues,
though.
In that case, scratch my comments about cancellable futures. Instead,
keep .remove(), but just let it accept the future returned by .add().
No reason to abstract through a string when you've got a handy object
already there. That way you can kill the .id property entirely.
My comments about potentially killing .clear() stand, though. It may
be convenient to keep, but we can drop it if it can't justify itself.
~TJ
Received on Wednesday, 8 May 2013 19:29:54 UTC