Michael 'Mickey' Lauer wrote: >>> I felt a dbus interface for that would be nice. It's not in use >>> yet, but we need something like that anyways when we want to support >>> waking up arbitrary dbus clients for PIM events. >> What about a interface where a process can register a timer event for a >> callback/dbus signal? >> Getting and setting stuff to the clock does not sound to me like >> something that needs to be exposed as a interface. > > Ok, how would you design it then? Lets say we have a couple of clients who > know about certain appointments and every time you go into suspend, you need > to find out which client knows about the soonest appointment and have the RTC > programmed accordingly.
The back end only needs to keep the soonest timer in the clock and change to the next if the time passed. And emit messages when a timer is passed. > How do these programs know each other? Are all supposed to concurrently > program the RTC? => Boom. That's why i'm suggesting this abstraction. Programms should never set the rtc. They should just tell the backend that they need a timer for a specific time, and the backend can then make sure the system is running at this time and inform the client about the event. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
