Re: [Alarm API] Use cases

Hi Janusz,  

On Tuesday, 12 February 2013 at 22:28, Janusz Majnert wrote:

> 2013/2/12 Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)>:
> >  
> >  
> > On Tuesday, 12 February 2013 at 08:52, Robin Berjon wrote:
> > > On 12/02/2013 08:40 , Christophe Dumez - SISA wrote:
> > > > The way I see it. The application that registered the alarm gets
> > > > spawned if it is not currently running and the alarm goes off. Then,
> > > > the "alarm" event is fired.
> > >  
> >  
> >  
> > If the app is closed, this means reconstructing the whole application's DOM, etc. Imagine it was a game that set the alarm, and it has to load all its needed resources (could include ones that require communication over HTTP), JS libraries, and so on (and make sure you navigate to the correct page). This sounds very heavy + memory + cpu + battery intensive and for what use case in particular? If the actual use case was to notify the end-user of something ("Your spaceship has landed on planet Xubar!"), then it should have instead scheduled a notification for some given time (a "scheduled notification", as opposed to a "push notification").
>  
> It doesn't necessarily need to be like this. The application that
> registered the alarm will be launched (I presume we will soon decide
> what the "initial" state in the app lifecycle is) and the alarm event
> will be fired.

Any idea at what point should it be fired? And what happens if this is a multipage application (or would the "main" html page be always the target)?  
> What the application does with the alarm is entirely up
> to itself.  

Sure. But again, I'm not getting a very clear use case (some comments below about the ones you listed … I'm not saying there are none, I'm just struggling a bit to understand what they are). I'm also worried about "spammy" applications that become impossible for the user to kill:

window.onclose = function(){
// create alarm to open app 10 minutes later and remind you to buy my crap! :)
};  
> If it decides to load some resources or access any other
> APIs, it will still be bound by the rules we set for the APIs. I agree
> that it may be confusing for the user to unlock their phone and find
> an application launched (in foreground/background).

This could potentially be problematic if it unlocks in your pocket (and start making phone calls accidentally, etc.).   
> On the other hand
> Android does this all the time (all those Google services running for
> no apparent reason).

heh:) I've personally have not experienced this (I'm still using my trusty Samsung GT-9000 with Androind 2.2.x, aka "the workhorse"). Is this a 4.x thing?   
> All in all, a well behaved app should handle the alarm in a way that
> will not annoy the user.

I'm not too concerned about well behaving apps; I'm concerned about the ones that use the API naively or maliciously. In the wrong hands, this API can do some seriously annoying things.
> > I ran the idea of adding time to the Web Notifications API with Annevk, and he seemed open to it… maybe something to consider.
>  
> Notifications are not enough IMHO. With the Alarm API we want to be
> able to actually do some application specific work, not just display a
> message. For example an email or Twitter app might want to download
> updates and then show a notification.

I'm a bit worried about the above use cases personally (and I know you are just giving examples). But as someone who is on pre-paid (and travels a bit), I don't want apps to ever do this. I only want apps to download stuff for me if I initiated this action (e.g., I open Twitter and I open my email). Otherwise, this API will need a serious permissioning model as it could potentially cost the user a great deal of money.   
> I agree that we should clearly specify what to do with the alarms that
> cannot be "delivered" due to various conditions (like power off). I
> wonder how cron handles this?

Quick reading is that if the machine is off, cron won't queue stuff. To queue, you need something like Anacron:
http://www.ibm.com/developerworks/linux/library/l-anacron/?ca=dgr-lnxw06Anacron&S_TACT=105AGX59&S_CMP=grlnxw06

Received on Tuesday, 12 February 2013 23:14:53 UTC