Re: Web Alarm API - idiomatic check

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

Received on Wednesday, 8 May 2013 19:08:41 UTC