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.
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
