Re: Web Alarm API - idiomatic check

On 15/05/13 23:18, Jonas Sicking wrote:
> 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.

That's a fair point.

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

I would argue that the cost/benefit of this method isn't high but given
that there is no strong use cases for it, I guess we could always add it
later if needed.

--
Mounir

Received on Thursday, 16 May 2013 11:46:34 UTC