fso bug/oddity

[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.



-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.