Add experimental.alarms API to allow lazy background pages to

Add experimental.alarms API to allow lazy background pages to wake themselves up after a timeout.

BUG=81758
TEST=no

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=129495

[Aaron Boodman, 2012-03-27 00:40:39]

Sweet. Couple API issues before I look at the code:

Can we call this 'alarm' and put it in its own namespace? I think the API should
be more of a CRUD-type deal where you can create multiple alarms, list the
currently installed alarms, and delete alarms by ID. The reason I like 'alarm'
is:
- to distinguish clearly from setTimeout and friends
- because Android calls the similar API 'alarm'

There should probably be both one-shot and repeating type alarms.

Maybe the units should be something fairly large - like 1 minute. Just to make
it clear that this isn't a high resolution deal.

[Matt Perry, 2012-03-27 01:05:14]

On 2012/03/27 00:40:39, Aaron Boodman wrote:
> Sweet. Couple API issues before I look at the code:
> 
> Can we call this 'alarm' and put it in its own namespace? I think the API
should
> be more of a CRUD-type deal where you can create multiple alarms, list the
> currently installed alarms, and delete alarms by ID. The reason I like 'alarm'
> is:
> - to distinguish clearly from setTimeout and friends
> - because Android calls the similar API 'alarm'
> 
> There should probably be both one-shot and repeating type alarms.

Cool, I'll change to alarm. I'm not so sure about the value of registering
multiple alarms, because they will all dispatch the same onAlarm event.

> Maybe the units should be something fairly large - like 1 minute. Just to make
> it clear that this isn't a high resolution deal.

I considered this at first, but I think that using seconds is a good middle
ground because it gives us more freedom to tweak the granularity (e.g. if we
wanted 30-second bursts).

[Matt Perry, 2012-03-27 01:42:45]

OK, I moved it to a new namespace. I didn't add the RUD part of CRUD yet - still
not sure about it.

[Matt Perry, 2012-03-27 01:42:46]

OK, I moved it to a new namespace. I didn't add the RUD part of CRUD yet - still
not sure about it.

[Matt Perry, 2012-03-27 22:59:39]

OK, added stubs for get/getAll/clear/clearAll. I think I'll defer the
implementation of those for a future CL.

[Aaron Boodman, 2012-03-27 23:34:01]

http://codereview.chromium.org/9791011/diff/9001/chrome/browser/extensions/ap...
File chrome/browser/extensions/api/alarms/alarms_api.cc (right):

http://codereview.chromium.org/9791011/diff/9001/chrome/browser/extensions/ap...
chrome/browser/extensions/api/alarms/alarms_api.cc:36: DictionaryValue* details;
Please use the JSON Schema compiler for new APIs.

http://codereview.chromium.org/9791011/diff/9001/chrome/common/extensions/api...
File chrome/common/extensions/api/experimental.alarms.json (right):

http://codereview.chromium.org/9791011/diff/9001/chrome/common/extensions/api...
chrome/common/extensions/api/experimental.alarms.json:24: "name": "set",
Seems like "create" would be a better name.

http://codereview.chromium.org/9791011/diff/9001/chrome/common/extensions/api...
chrome/common/extensions/api/experimental.alarms.json:32: "name": {"type":
"string", "optional": true,
Did you consider making the name a separate formal parameter? That was my first
inclination.

[Matt Perry, 2012-03-28 00:33:03]

http://codereview.chromium.org/9791011/diff/9001/chrome/browser/extensions/ap...
File chrome/browser/extensions/api/alarms/alarms_api.cc (right):

http://codereview.chromium.org/9791011/diff/9001/chrome/browser/extensions/ap...
chrome/browser/extensions/api/alarms/alarms_api.cc:36: DictionaryValue* details;
On 2012/03/27 23:34:01, Aaron Boodman wrote:
> Please use the JSON Schema compiler for new APIs.

Done.

http://codereview.chromium.org/9791011/diff/9001/chrome/common/extensions/api...
File chrome/common/extensions/api/experimental.alarms.json (right):

http://codereview.chromium.org/9791011/diff/9001/chrome/common/extensions/api...
chrome/common/extensions/api/experimental.alarms.json:24: "name": "set",
On 2012/03/27 23:34:01, Aaron Boodman wrote:
> Seems like "create" would be a better name.

Done.

http://codereview.chromium.org/9791011/diff/9001/chrome/common/extensions/api...
chrome/common/extensions/api/experimental.alarms.json:32: "name": {"type":
"string", "optional": true,
On 2012/03/27 23:34:01, Aaron Boodman wrote:
> Did you consider making the name a separate formal parameter? That was my
first
> inclination.

Done.

[Aaron Boodman, 2012-03-28 03:36:18]

LGTM w/ nits

http://codereview.chromium.org/9791011/diff/10003/chrome/browser/extensions/a...
File chrome/browser/extensions/api/alarms/alarms_api.cc (right):

http://codereview.chromium.org/9791011/diff/10003/chrome/browser/extensions/a...
chrome/browser/extensions/api/alarms/alarms_api.cc:24: void
SetAlarmCallback(Profile* profile, const std::string& extension_id) {
Maybe just AlarmCallback? How is this setting anything?

http://codereview.chromium.org/9791011/diff/10003/chrome/browser/extensions/a...
chrome/browser/extensions/api/alarms/alarms_api.cc:50:
params->alarm_info.delay_in_seconds*1000);
"*".wrap(" ");

http://codereview.chromium.org/9791011/diff/10003/chrome/common/extensions/ap...
File chrome/common/extensions/api/experimental.alarms.json (right):

http://codereview.chromium.org/9791011/diff/10003/chrome/common/extensions/ap...
chrome/common/extensions/api/experimental.alarms.json:26: "description": "Sets
an alarm. After the delay is expired, the onAlarm event is fired. If there is
another alarm with the same name (or no name if none is specified), it will be
overridden by this alarm.",
Creates an alarm. Will the old alarm be canceled in the case of overwrite? Or
will it still fire?

http://codereview.chromium.org/9791011/diff/10003/chrome/common/extensions/ap...
chrome/common/extensions/api/experimental.alarms.json:32: "description":
"Optional name to identify this alarm. Defaults to \"default\"."
How about just defaulting to empty string?

http://codereview.chromium.org/9791011/diff/10003/chrome/common/extensions/ap...
chrome/common/extensions/api/experimental.alarms.json:39: "description": "Length
of time in seconds after which the onAlarm event should fire. Note that
granularity is not guaranteed: up to a minute may pass before the alarm is
finally triggered."},
You could say: Accuracy is only guaranteed to within one minute (but then why
not just have units be minutes? -- your previous explanation didn't totally make
sense to me).

http://codereview.chromium.org/9791011/diff/10003/chrome/renderer/extensions/...
File chrome/renderer/extensions/schema_generated_bindings.cc (right):

http://codereview.chromium.org/9791011/diff/10003/chrome/renderer/extensions/...
chrome/renderer/extensions/schema_generated_bindings.cc:145: ". Did you remember
to register it with ExtensionFunctionRegistry?";
Heh.

Can we automate registration?

[Mihai Parparita -not on Chrome, 2012-03-28 17:01:30]

http://codereview.chromium.org/9791011/diff/10003/chrome/renderer/extensions/...
File chrome/renderer/extensions/schema_generated_bindings.cc (right):

http://codereview.chromium.org/9791011/diff/10003/chrome/renderer/extensions/...
chrome/renderer/extensions/schema_generated_bindings.cc:145: ". Did you remember
to register it with ExtensionFunctionRegistry?";
On 2012/03/28 03:36:18, Aaron Boodman wrote:
> Heh.
> 
> Can we automate registration?

I thought Mike and Antony's IDL work automates that step
(http://crrev.com/127159)

[Matt Perry, 2012-03-28 20:21:36]

http://codereview.chromium.org/9791011/diff/10003/chrome/browser/extensions/a...
File chrome/browser/extensions/api/alarms/alarms_api.cc (right):

http://codereview.chromium.org/9791011/diff/10003/chrome/browser/extensions/a...
chrome/browser/extensions/api/alarms/alarms_api.cc:24: void
SetAlarmCallback(Profile* profile, const std::string& extension_id) {
On 2012/03/28 03:36:18, Aaron Boodman wrote:
> Maybe just AlarmCallback? How is this setting anything?

It was (SetAlarm)Callback, not Set(AlarmCallback) :) - from back when the API
was setAlarm. But you're right, I'll change it.

http://codereview.chromium.org/9791011/diff/10003/chrome/browser/extensions/a...
chrome/browser/extensions/api/alarms/alarms_api.cc:50:
params->alarm_info.delay_in_seconds*1000);
On 2012/03/28 03:36:18, Aaron Boodman wrote:
> "*".wrap(" ");

Done.

http://codereview.chromium.org/9791011/diff/10003/chrome/common/extensions/ap...
File chrome/common/extensions/api/experimental.alarms.json (right):

http://codereview.chromium.org/9791011/diff/10003/chrome/common/extensions/ap...
chrome/common/extensions/api/experimental.alarms.json:26: "description": "Sets
an alarm. After the delay is expired, the onAlarm event is fired. If there is
another alarm with the same name (or no name if none is specified), it will be
overridden by this alarm.",
On 2012/03/28 03:36:18, Aaron Boodman wrote:
> Creates an alarm. Will the old alarm be canceled in the case of overwrite? Or
> will it still fire?

Done (it will be cancelled).

http://codereview.chromium.org/9791011/diff/10003/chrome/common/extensions/ap...
chrome/common/extensions/api/experimental.alarms.json:32: "description":
"Optional name to identify this alarm. Defaults to \"default\"."
On 2012/03/28 03:36:18, Aaron Boodman wrote:
> How about just defaulting to empty string?

Done.

http://codereview.chromium.org/9791011/diff/10003/chrome/common/extensions/ap...
chrome/common/extensions/api/experimental.alarms.json:39: "description": "Length
of time in seconds after which the onAlarm event should fire. Note that
granularity is not guaranteed: up to a minute may pass before the alarm is
finally triggered."},
On 2012/03/28 03:36:18, Aaron Boodman wrote:
> You could say: Accuracy is only guaranteed to within one minute (but then why
> not just have units be minutes? -- your previous explanation didn't totally
make
> sense to me).

I'm trying to give us some leeway as to how accurate alarms are, and not tie it
directly to the units. If we want to allow alarms every 30 seconds, for example,
we need to use seconds as the units. And if we want to reduce granularity to
every 5 minutes, using minutes as units doesn't convey that either. I'll update
the description and try to convey this better.

http://codereview.chromium.org/9791011/diff/10003/chrome/renderer/extensions/...
File chrome/renderer/extensions/schema_generated_bindings.cc (right):

http://codereview.chromium.org/9791011/diff/10003/chrome/renderer/extensions/...
chrome/renderer/extensions/schema_generated_bindings.cc:145: ". Did you remember
to register it with ExtensionFunctionRegistry?";
On 2012/03/28 17:01:31, Mihai Parparita wrote:
> On 2012/03/28 03:36:18, Aaron Boodman wrote:
> > Heh.
> > 
> > Can we automate registration?
> 
> I thought Mike and Antony's IDL work automates that step
> (http://crrev.com/127159)

Ah, cool, it does. Unfortunately it doesn't quite work with all the JSON files
yet:
- it generates the schema.json data, which is unnecessary for JSON files.
- it assumes a particular naming scheme for ExtensionFunctions, which is not
obeyed by all the JSON APIs.