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

Re: Web Alarm API - idiomatic check

From: Joshua Bell <jsbell@google.com>
Date: Wed, 8 May 2013 15:15:24 -0700
Message-ID: <CAD649j7T+0B_a49=+Acrh98RNvmw2wGSQugnLJiLiMxzb=nG6Q@mail.gmail.com>
To: Jake Verbaten <raynos2@gmail.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Marcos Caceres <w3c@marcosc.com>, public-script-coord <public-script-coord@w3.org>
Other parts of the web platform (MessagePort, IndexedDB, ...?) go beyond
JSON-serializable payloads to the HTML "structured clone" algorithm. Is
there a reason to limit the alarm payload to just JSON-serializable?

The spec should also more concretely state that the data is actually
serialized (and/or cloned) when the add() method is called. Otherwise, one
might assume you can do:

var payload = { a: 1 }
navigator.alarms.add(new Date(2525, 0, 1), "ignoreTimeZone", payload);
payload.b = 2;

... and have the additional property show up, and/or object identity if the
alarm fires within the same browsing session.

The spec also needs to define the behavior if the data is not serializable;
you probably want to throw DataCloneError. (Sticking with JSON-serializable
also seems to be odd around edge cases.... it lets some objects implement
toJSON() to get lossily-serialized, while forbidding other types like typed

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

> > 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.
Agreed. Suggest moving the "How to register a listener for an alarm"
example further up, so that the intro starts off with the most basic
schedule/listen pair.

> 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 22:15:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC