Re: Web Alarm API - idiomatic check

> though this is partially due to my ignorance of "system messages".

I second that the references to system messages are too light and easy to
miss.


On Wed, May 8, 2013 at 2:16 PM, Jake Verbaten <raynos2@gmail.com> wrote:

> a handy object is hard to persist on the server or persist in local
> storage between page refreshes.
>
> .remove() should take a string or numeric id if you can use .remove()
> between page refreshes
>
>
> On Wed, May 8, 2013 at 12:29 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:
>
>> On Wed, May 8, 2013 at 12:14 PM, Jake Verbaten <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.
>>
>> ~TJ
>>
>
>