On 1/12/06, Florian Boor <[EMAIL PROTECTED]> 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 _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
