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://
bugzilla.osafoundation.org/show_bug.cgi?id=5407).
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
usage. :)
[[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
here).
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. :)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
