[Chandler-dev] Proposal/Call for volunteers/Brain dump:
Showing reminders when Chandler isn't running
Phillip J. Eby
pje at telecommunity.com
Wed Jul 5 21:46:38 PDT 2006
At 06:08 PM 7/5/2006 -0700, Grant Baillie wrote:
>One commonly found Calendar feature that we'd like to implement is
>the ability to have reminder dialogs for events be displayed even
>when the Chandler GUI isn't visible (see https://
>Presumably, this would be something users could turn on and off, lest
>we be accused of propagating some kind of CPU-hogging virus :). It's
>unlikely we'll have time to do this in the Î±4 time frame, but I'd
>like to request comments and/or propose some ideas for how we could
>get this done.
>Also, since I'm somewhat of a Mac guy, and solving the issue will
>probably require different behaviours on Windows & Linux, it would be
>good to enlist the help of people who know the other platforms well.
>For instance, there may be OS-specific services that I'm not aware of
>that could be helpful here. The main technical stumbling block that I
>see is one that probably has a platform-specific answer:
>+++ How do we make sure that some kind of background process or app
>runs whenever the user is logged in?
Have you considered just using the OS's scheduling facilities to run things
when they're actually scheduled? That way, the program wouldn't need to
run all the time.
Of course, in the limit case you could just run something like a "sleep"
command followed by the notifier. That at least would be very low resource
>[[For instance, on the Mac, you can add a "background" app to the
>user's list of login items; in 10.4 (Tiger) there may be a way to
>leverage launchd. I know there's a Service facility on Windows you
>can use to launch background processes, though I'm not sure if this
>would be the right thing to be using. What's the story with Linux?
>Probably there are mechanisms in KDE/Gnome... ]].
I'm not sure if services are something that launch at login or not, but I
do believe that normal Windows startup entries ought to work.
>2) Have two processes, but have the background daemon not use the
>repository at all. (Maybe we're worried that people will try to store
>their repositories on volumes that don't support file locking, or
>something). Instead, the two communicate via a config file and/or
>named pipes or something (insert sound of two hands waving profusely
XML-RPC, perhaps? :) Actually, a relatively simple IPC technique would be
to just dump reminder files in a directory, renaming them from a temporary
name when their content is completely written. The reminder program just
reads the directory to see what files are there, and reads files it hasn't
seen. If a reminder's date has passed, it deletes the file. The files
have to be uniquely named, and also contain an identifier to allow changes
to be processed. (Because if there's a schedule change, you can't just
rewrite the original file; the directory is a message queue, not a
database.) This approach is *very* robust, as the two processes don't have
to be running at the same time to communicate, there are no locking issues
and nothing that can be corrupted, and it should be able to work correctly
even on Windows. :)
More information about the chandler-dev