[maemo-developers] [maemo-developers] Maemo alarms ==> retutime

[From: Weinehall David (Nokia-M/Tampere)]

On mån, 2006-07-31 at 07:05 -0500, ext David D. Hagood wrote:
> Igor Stoppa wrote:
> > On Mon, 2006-07-31 at 13:29 +0200, ext Nils Faerber wrote:
> > [snip]
> >> And even worse since the alarms can only be set <24h in advance does
> >> that indeed mean that every application that wants to use alarms would
> >> have to handle this nasty 24h hopping on its own? I.e. if the alarm is
> >> more than 24h in the future then set an alarm for <24h, then check again
> >> and set a new alarm until it is less than 24h away?
> >> 
> >> That is messy, indeed.
> > Sure. A framework would help but the hw limitation is still there.
> > 
> 
> I've dealt with this sort of limitation in some embedded systems I've 
> developed, and it's really not a problem *if* you have a central entity 
> managing the alarms - you just maintain a list of alarms, sorted in 
> order of firing time. Every time the list changes, you re-evaluate the 
> head of the list (first alarm to fire) and set the hardware up accordingly.
> 
> So if there were a service that apps registered themselves with, and 
> that service maintained the list, then the problem is solved.
> 
> And, in the spirit of being as "Unix-y" as possible, if that service 
> supplied cron/at support as well, then that would be even better.

We have solved all (hopefully) the technical problems by design
workarounds (such as the need of wakeups every 24h to re-program the RTC
alarm if there are pending alarms), but releasing an implementation
simply wasn't prioritised for the 2006 edition of the software.


Regards: David
-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?