Code review comment for lp:~charlesk/indicator-datetime/lp-1233176

On Mon, 2013-10-14 at 09:28 +0000, Matthew Paul Thomas wrote:

> > When an alarm is triggered, the indicator date-time should only
> create a snap decision
>
>
>
> I'm surprised that indicator-datetime is doing *anything* with alarms
> other than listing them. What if I install an alternative calendar
> app? What if I install a sleep app with an alarm that goes off within
> a half-hour window, such that indicator-datetime can't display its
> exact time in advance? What if we decide to redesign the status bar
> such that indicator-datetime is no longer used? None of that should
> affect whether alarms go off. That should be up to the app, not a menu
> that happens to (but doesn't inevitably) display upcoming alarms.

Apps are not allowed to run in the background, and we don't want them
to. What we're allowing is them to add events to a shared calendar, and
then having a service that looks at that shared calendar and prompts the
user if they want to act at that time. That service happens to be
indicator-datetime today as it already has to have that information to
display it in the indicator. There is no technical reason it has to be
indicator-datetime in the future, just a convenience for implementation
today. If the user does interact with the snap decision or click on the
item in the indicator at that time we are invoking the app to do what it
wishes.