Michael 'Mickey' Lauer
mickey at openmoko.org
Wed Sep 17 19:12:37 CEST 2008
Am Wednesday 17 September 2008 18:52:16 schrieb Tilman Baumann:
> 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.
Heh, sounds we're on the same page then.
org.freesmartphone.Device.RealtimeClock always belonged to the lower level
dbus interfaces in my thinking (as are most of the other .Device.* ones). I
want to use this from the PIM agent, but not from any app.
More information about the community