On Wed, 5 Jul 2006, Grant Baillie wrote:
1) Have two separate processes, the app and a background daemon/service, that both access the user's repository. The way I understand things (Andi, correct me if I'm wrong), both processes would need to poll (via the repository view refresh() API) to detect when changes have occurred. It turns out Chandler does this already (in a wx idle event callback), while the reminder process could presumably just check every minute (if it's not displaying any UI).
Yes, that should 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).
It is a requirement that the repository files be stored on a file system that supports proper locks. This is a Berkeley DB requirement. Berkeley DB supports multiple processes accessing the repository just as well as multiple threads.
4) Have just one process, today's Chandler, but add the ability for it to switch between full UI & background (reminder-only) mode. So, if background mode is in effect, and the user launches Chandler, a little plastic garden gnome waves a sparkly wand and tells the background process to display the full UI. Similarly, when you "quit" the full UI app, it goes back into background (stealth) mode. (This is easier, so the gnome gets a break).
Somehow, having multiple processes, one for each task seems cleaner. Andi.. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
