Re: Web Alarm API - idiomatic check

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

It's also not clear whether these alarms are persisted in the device across
device restarts and browser restarts.

If I shut down my application and restart it and then shutdown my computer
and restart it, will the alarm still go off if my web application happens
to be open at the time of the alarm?

What about sharing the alarms across multiple browsers?

In fact it's not clear whether alarms are stored and handled in the device
or in the browser.


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

> On Wed, May 8, 2013 at 10:54 AM, Marcos Caceres <w3c@marcosc.com> wrote:
> > Hi,
> > The SysApps WG would appreciate if the JS folks could take a look at:
> > http://web-alarms.sysapps.org/
> > (it's nice and small, promise)
> >
> >
> > And provide us some feedback on the idiomatic aspects (i.e., to make
> sure it isn't "another crap W3C API"™).
> >
> > A disclaimer: The API's name is terrible, we know that (should be called
> Web Cron or Web Scheduled Tasks or something less awful). We've tried to
> use Futures, but we are new to them.
>
> I support WebCRON - for a useful subset of people it's
> self-explanatory; for other people, it's a useful nonce word which
> distinguishes it from anything else.
>
> > Anyway, any/all, comments welcome.  If you want to file bugs directly
> (or see what bugs we have open):
> > https://github.com/sysapps/web-alarms/issues/ (
> https://github.com/sysapps/web-alarms/issues/new)
>
> Okay, so the core API is alarms.add(), which creates a future which is
> resolved at the specified time.  It's magic, because the futures are
> managed by the system, and if the app isn't active when the future
> resolves, the system will start the app with the future still present.
>
> When an app goes down, how does this affect callbacks the system is
> saving?  That is, since you're registering callbacks at some point,
> the registered functions are capturing their surrounding lexical
> state.  Does that get saved along with the callback when the app goes
> down, so that if it gets restarted, the callbacks still have the same
> lexical state as before?  I assume that the earlier event-based
> version didn't have this issue, because the app would just register
> its handlers on startup, and then receive the message with its
> freshly-created callbacks.
>
> Jake points out that you've now hidden *all* the information about the
> alarm in the resolved future value, which means that it's impossible
> to know what the alarm id is for cancelling until it's too late to
> cancel it.  However, the setTimeout style of using ids to cancel
> things was clumsy and bad in the first place.  What you really want
> is, instead, a CancellableFuture, which we haven't defined quite yet,
> but are discussing in public-script-coord.  That way you can cancel a
> pending operation just using the future object directly.  This would
> let you kill the .remove() function entirely.
>
> Similarly, you could then kill .clear() if you wanted, as people could
> just call getPendingAlarms().then(alarms=>alarms.forEach(x=>x.cancel()));
>
> Why is getPendingAlarms() async?  Is that a required part of its
> contract, because the information is stored somewhere that may be
> slow?  If not, just have it return an array of alarms.
>
> ~TJ
>
>