fso bug/oddity

[Michael 'Mickey' Lauer]

Am Wednesday 17 September 2008 18:24:30 schrieb Tilman Baumann:
> Michael 'Mickey' Lauer wrote:
> > Am Wednesday 17 September 2008 17:54:54 schrieb Tilman Baumann:
> >> Michael 'Mickey' Lauer wrote:
> >>> Am Wednesday 17 September 2008 16:16:43 schrieb Tilman Baumann:
> >>>> Tilman Baumann wrote:
> >>>>> dbus is getting flodded by org.freedesktop.Gypsy.Time.TimeChanged,
> >>>>> org.freedesktop.Gypsy.Satellite.SatellitesChanged and
> >>>>> org.freedesktop.Gypsy.Time.TimeChanged signals.
> >>>>> But GPS is off.
> >>>>>
> >>>>> I think neither of the events makes sense in this case and wastes
> >>>>> cycles. Probably not good for battery life.
> >>>>
> >>>> I just had a look at the fso apis again. And i almost fell of my
> >>>> chair. I just found org.freesmartphone.Device.RealtimeClock
> >>>> What is wrong with gettimeofday anc co with all it's beauty?
> >>>
> >>> Last time I checked gettimeofday reads from system time.
> >>> org.freesmartphone.Device.RealtimeClock is a dbus interface to program
> >>> the RealtimeClock (sic!).
> >>
> >> My mistake. But what about /dev/rtc and the hwclock command?
> >
> > programming /dev/rtc works fine from C and asm, much less so for higher
> > level languages.
>
> But they will however probably never be in a position where they need to.
> Keeping the rtc in sync sounds to me like a framework job.
>
> I don't know, the system clock should probably be stored in rtc before
> going to sleep and saved back afterwards.
> And the usual stuff, shutdown and booting.
>
> > 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.

How do these programs know each other? Are all supposed to concurrently 
program the RTC? => Boom.

> Sorry if my sarcasm sounded too harsh. It isn't all that bad. ;)

Don't worry, I'm sarcasm-resistent by now. It's important though that people 
understand why we need all these abstractions. It's not because we love high 
level interfaces, it's because we need to prepare for application 
_integration_.

-- 
:M: