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

Re: Web Alarm API - idiomatic check

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 15 May 2013 15:18:29 -0700
Message-ID: <CA+c2ei8ck0HaMP0VSS4GaXmR-bvL+sY1NhLsWb5wxm-KcZhmcg@mail.gmail.com>
To: Mounir Lamouri <mounir@lamouri.fr>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On Wed, May 15, 2013 at 6:44 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:
> On 09/05/13 21:42, Christophe Dumez - SISA wrote:
>> 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()));
>
> .clear() has a performance advantage compared to
> .getPendingAlarms().then(alarms=>alarms.forEach(x=>x.cancel())): when
> you use .clear() there will be only one DB access that will remove every
> alarm that belongs to the caller. Using .cancel() for each alarm might
> do as much calls to the DB which is going to be significantly slower. It
> is possible to argue that a clever implementation could delay the DB
> access so it can perform multiple operations at the same time but I
> think having a .clear() method is a syntax sugar that could make life
> easier for developers and implementations and it is worth taking.

How common is it for applications to need to cancel all alarms though?
I can't think of any use cases other than "complete system reset",
which I don't think is a common UI to expose to users from within an
app.

The only reason that I think we ended up with .clear() in the contacts
API (which as I understand it this was copied from) was that it was
useful during testing and development of the API itself. Hardly
something we should optimize for.

/ Jonas
Received on Wednesday, 15 May 2013 22:19:26 UTC

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