Re: Web Alarm API - idiomatic check

It isn't clear to me why the AlarmManger methods need to be asynchronous.  Obviously the actual delivery  of alarms must be asynchronies but I would think that registration and subsequent management of the alarm queue could be done synchronously and that it would be a simpler API if that could be done so. For example, it easy to define the meaning of getPendingAlarms  if it returns synchronously.  But if it is asynchronous then there is the issue of "pending" as of when, the time of the getPendingAlarms call or the time when the future is resolved?  What happens if an Alarm goes off between the call and the resolution.

Allen

On May 8, 2013, at 11:10 AM, Domenic Denicola wrote:

> The futures usage looks reasonable, but there still seems to be a lot of event-handler cruft left over? Especially in the opening example?
> 
> One thing that confused me is the repeated "If an error occurs" verbiage. How could an error occur? The phrase "error" only occurred in the document inside those phrases, so I'm not sure what's going on there.
> 
> ________________________________________
> From: Marcos Caceres [w3c@marcosc.com]
> Sent: Wednesday, May 08, 2013 13:54
> To: public-script-coord
> Subject: Web Alarm API - idiomatic check
> 
> 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)
> 
> Kind regards,
> Marcos
> 
> 
> 
> 
> 
> 
> 
>

Received on Wednesday, 8 May 2013 18:47:21 UTC