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

Re: Web Alarm API - idiomatic check

From: Jake Verbaten <raynos2@gmail.com>
Date: Wed, 8 May 2013 14:16:58 -0700
Message-ID: <CAMCMjp0sdG3UkVnJi9n4YeMTQuNYkgU0SL9jcRaoUtfMu-CHYg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Marcos Caceres <w3c@marcosc.com>, public-script-coord <public-script-coord@w3.org>
a handy object is hard to persist on the server or persist in local storage
between page refreshes.

.remove() should take a string or numeric id if you can use .remove()
between page refreshes

On Wed, May 8, 2013 at 12:29 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> 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 21:17:25 UTC

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