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

RE: Web Alarm API - idiomatic check

From: Christophe Dumez - SISA <ch.dumez@partner.samsung.com>
Date: Thu, 9 May 2013 20:42:43 +0000
To: Marcos Caceres <w3c@marcosc.com>, Tab Atkins Jr. <jackalmage@gmail.com>
CC: Jake Verbaten <raynos2@gmail.com>, public-script-coord <public-script-coord@w3.org>
Message-ID: <1147D1694C8E994D99943F21EC61E97F010F3075@sisaex02sj>
Hi,

I commented on that bug. If I remember correctly, clear() was added for consistency with the Contact API.
It is merely a convenience function so I don't have strong feeling either way.

However, I do think that clear() is a lot more readable than getPendingAlarms().then(alarms=>alarms.forEach(x=>x.cancel()));

Kr,
Christophe DUMEZ.
________________________________________
From: Marcos Caceres [w3c@marcosc.com]
Sent: Thursday, May 09, 2013 23:36
To: Christophe Dumez - SISA; Tab Atkins Jr.
Cc: Jake Verbaten; public-script-coord
Subject: Re: Web Alarm API - idiomatic check

On Wednesday, May 8, 2013 at 8:29 PM, Tab Atkins Jr. wrote:

> On Wed, May 8, 2013 at 12:14 PM, Jake Verbaten <raynos2@gmail.com (mailto: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.
>

I've filed a but about killing clear.
https://github.com/sysapps/web-alarms/issues/39

Christophe, any thoughts?

--
Marcos Caceres
Received on Thursday, 9 May 2013 20:43:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC