[maemo-developers] [maemo-developers] Maemo Alarm/Notifier Interface

[From: Dave Neuer]

On 1/12/06, Florian Boor <florian.boor at kernelconcepts.de> wrote:
> Hi,
>
> Devesh Kothari wrote:
> >    - Events must be delivered regardless of the device state e.g sleep,
> > deep sleep or poweroff state [but with battery plugged in]
>
> I'm not sure if poweroff is really necessary... it would be cool if it is
> possible but i suppose we could live without this if it is complicated to implement.

Am I missing something here or just misunderstanding the meaning of
the phrase "Events must be delivered;" if it means "Events must be
delivered, but possibly late (e.g. if event fired while in poweroff
state)" then that sounds like no problem. However, isn't the
definition of hard poweroff that there is no state machine operating
which can wake the system?

>
> >    - User should be able to schedule Events/Notification in any future
> > time e.g my mothers birthday which is 8 months away.
>
> Definitely...

<snip>

> >   - The ability to cancel/enable alarm might make things complicated for
> > application developers, as then events not delivered to the registered
> > apps, somebody need to tell them that the alarm was either cancelled or
> > rescheduled, so they can reach a sync state.
>
> Well... usually applications will use both an alarm signal and some notification
> on screen. If the alarm signal is disabled by a system state and no user input
> received the device should just go to sleep again. Some system message
> indicating a missed alarm if the evice state is changed might be another
> possible way to deal with this.

I see all three of these points as related and pointing to a solution
which is something like what, IIRC, gpe-calendar does WRT layering
functionality:

1) Some app or lib is responsible for recording/managing events. This
app knows what events were supposed to go off, is notified by (2) when
an event occurs, and is responsible for notifying apps that a) event
has just occurred; b) event expired while device was powered off; c)
event was otherwise cancelled by user, etc.

2) A kernel-level state machine which actually registers the timers
for events and notifies (1) when they occur.

Dbus seems like an appropriate channel for propagating events between
(1) and (2).

Any system w/ Dbus and "libalarm" or whatever would be able to offer
apps the same API.

Dave