- From: Marcos Caceres <w3c@marcosc.com>
- Date: Thu, 9 May 2013 21:30:11 +0100
- To: Jorge <jorge@jorgechamorro.com>
- Cc: public-script-coord <public-script-coord@w3.org>, Christophe Dumez - SISA <ch.dumez@partner.samsung.com>
On Wednesday, May 8, 2013 at 10:56 PM, Jorge wrote: > 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) heh. Hopefully Jonas' email clarified this [1]. > 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()) So, [1]… but yes, maybe the names could be improved. getPendingAlarms() could really just be .pending() or .getPending(); Saying navigator.alarms.get*Alarms() is tautological, IMO. WDYT? > To clear all the alarms a getAlarms().forEach(a => Navigator.Alarms.clear(a.id)) would do. Again, can't do this sync. But: getAlarms().then((alarms) => alarms.forEach(a => Navigator.Alarms.clear(a.id)) ? It's not too traumatic with .then(). > Does Alarms have to hang from the Navigator object? I was going to ask the same thing! For static functions, would it not be better to make the statics on the interface object? So the AlarmManager interface should just be called CronJobs. So then: var f = CronJobs.add(..); and so on… less typing, and no more navigator.alarms - and makes actual use of the AlarmManager object which is sitting uselessly on the Window object. Thoughts? > 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? > Not sure TBH. Christophe? [1] http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0446.html
Received on Thursday, 9 May 2013 20:30:42 UTC