fso bug/oddity

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 mailing list