W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Web Alarm API - idiomatic check

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 8 May 2013 12:29:08 -0700
Message-ID: <CAAWBYDA5Tvjnk614sFn6isqK3tbtr2D6O+ORponuaxv375hs5w@mail.gmail.com>
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,

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.

Received on Wednesday, 8 May 2013 19:29:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC