Re: Web Alarm API - idiomatic check

On 08/05/2013, at 19:54, Marcos Caceres wrote:

> Hi,  
> The SysApps WG would appreciate if the JS folks could take a look at:
> http://web-alarms.sysapps.org/
> (it's nice and small, promise)
> 
> And provide us some feedback on the idiomatic aspects (i.e., to make sure it isn't "another crap W3C API"™).  
> 
> A disclaimer: The API's name is terrible, we know that (should be called Web Cron or Web Scheduled Tasks or something less awful). We've tried to use Futures, but we are new to them.  
> 
> Anyway, any/all, comments welcome.  If you want to file bugs directly (or see what bugs we have open):
> https://github.com/sysapps/web-alarms/issues/ (https://github.com/sysapps/web-alarms/issues/new)

Why is the API asynchronous?

Is listing/setting/clearing/removing alarms such an expensive/longish operation so as to justify an async API?

Or is it now the w3c's policy to provide solely future/promise-ish APIs for everything :-) ? (perhaps a sync API would suffice here)

Oh, and the names are needlessly long imho (we're going to have to type them!):

Alarms.getAlarms(): returns an array of alarms (not an alarmsList).
Alarms.set(params): returns an alarm object (why not simply the id?) or null if error (can this err?). (set, as in setTimeout())
Alarms.clear(alarm.id): return true or false if err (can this err?). (clear, as in clearTimeout())

To clear all the alarms a getAlarms().forEach(a => Navigator.Alarms.clear(a.id)) would do.

Does Alarms have to hang from the Navigator object?

Isn't it better to use the alarm object's identity to identify an alarm instead of an id? An id can be guessed: does it matter?
-- 
( Jorge )();

Received on Wednesday, 8 May 2013 21:56:37 UTC