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

[From: Devesh Kothari]

Great this is feedback I was looking for. Now just to bring on same page
again

First the end user use cases
1. An application e.g Calender or task wanting to alart and notify the
user of scheduled events. This notification should have a certain
accepted granularity and delivery promise
   - Resolution of most end user use case can live with 1 minutes
granularity [IMHO]
   - Events must be delivered regardless of the device state e.g sleep,
deep sleep or poweroff state [but with battery plugged in]
   - User should be able to schedule Events/Notification in any future
time e.g my mothers birthday which is 8 months away.

Every other use case is more secondary use case
2. User is able to work on all scheduled events from one common point 
UI (e.g as simon pointed, in a cinema, want to silent all alarms, cancel
or enable alarms).
  - You can argue that switching off the device speaker would result the
same, though you might have the nuisance of screen turn ons.
  - 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.

>From a Developer Perspective
1. There should be a easy to use API enabling/disabling and notification
of scheduled events.
2. Alarm/Notifier sub system should have the capability to delivery
events to applications, even in case the application is not running [e.g
starting the app with a specific startup reason code, so that the whole
app window need not be started e.g in case of calendar, only a dialog
pops up saying event due ... with option like open event (causing all
app window to come), reschedule/snooze, cancel
3. It would also be useful that the implemented solution is also
available/complaint/builds upon other solutioins like that mentioned
about hh.org and iPAQs
4. IN case of reshedule, or cancel, only the app which scheduled it, is
able to do that [some kind of inbuild security]

What I have learnt on this discussion thread
First the hardware
- On n770 RTC is the provided by retu, which has a granularity of 1
minutes and can only handle 1 event at a time and that too for only
between now and 23:59
- I am assuming that it is capable of waking up the hardware, even if it
is powered off [but with a alive and kicking battery]

About the implementation (As a application developer I would not care
about the real implementation, till I can get a simple to use API
interface enabling basic use cases :) but from Maemo perspective, it is
benificial that the Maemo development Platform get a sane design.

- some kind of D-BUS to auto activate and deliver events
- some kind of library to abstract the inner working of the
implementation [good also from point of view of application
portability], could be extension to lib_osso or another brand new
lib_alarm or whatever. This should also enable simultaneous concurrent use.
- some kind of UI , maybe a control panel applet to work with all
alarms/events scheduled. Now that depends if it is free for all to know
about all events scheduled by other apps [not so nice from security
point of view, so if security of this time is important then to drop
this completely]
- some sort of a daemon to provide software intelligence to make up for 
hardware constrains.
- existing open source components should not be changed e.g reduces
maintainence overhead (proposals being crond, atd)


I think it would be good idea to have a wiki page?  My objective is
quite achieved that there is community participation, and people inside
nokia  need to look  into what the community had wanted and what was
delivered :) even when I know product  schedules and  requirements are
highest priority [read as , you wont get always what you wanted ;)].

cheers
Devesh








ext Igor Stoppa wrote:

>On Wed, 2006-01-11 at 11:35 -0800, ext Jason Mills wrote:
>  
>
>>A few items:
>>
>>0) The RTC subsystem is served off a chip known as "Retu". Most of the ASICs
>>on the Nokia 770 board seem to have nice nordic names to them. :-)
>>
>>
>>1) The RTC subsystem only supports one future alarm event, and that event may
>>not be more than 24h59m from "now". Maximum alarm granularity is +/-1 minute
>>or so.
>>    
>>
>23h59m if memory serves me well
>
>Only Retu can wake up the device from poweroff state at a preset time;
>unfortunately this is the time resolution that it canprovide. In order
>to extend alarms and events scheduling one could have the daemon
>scheduling periodic wakeups (every 24h) till the real alarm is closer
>than 24h.
>The granularity problem could be overcome using either a sw timer or an
>internal HW timer, with better resolution than 1m.
>It would be programmed by the daemon, after the last wakeup and  before
>reaching the scheduled time for the event.
>
>  
>
>>2) The actual definition of "now" is a bit arbitrary, because of how the RTC
>>synchronization works.
>>
>>
>>3) There is a functional, albeit spartan CLI utility already available to
>>talk to the RTC subsystem, -and- to set/check the alarm.
>>/mnt/initfs/usr/bin/retutime
>>
>>
>>4) The osso_alarm and osso_notifier daemons are missing at least from the
>>2005.51 Nokia build. No bug is currently filed against this, and I haven't
>>had a chance to file one yet. I think, though am not 100% sure, that these
>>two daemons are required in order to fetch the actual alarm signal from the
>>RTC subsystem.
>>
>>
>>-JMills
>>_______________________________________________
>>maemo-developers mailing list
>>maemo-developers at maemo.org
>>https://maemo.org/mailman/listinfo/maemo-developers
>>    
>>
>
>  
>