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

Re: Web Alarm API - idiomatic check

From: Jake Verbaten <raynos2@gmail.com>
Date: Wed, 8 May 2013 14:17:34 -0700
Message-ID: <CAMCMjp0ora3=Z8eWFkvet0XNvc+GE8APBc79RU3HY_+8-j7Pqg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Marcos Caceres <w3c@marcosc.com>, public-script-coord <public-script-coord@w3.org>
> 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
>>
>
>
Received on Wednesday, 8 May 2013 21:18:01 UTC

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