On 19 Jul, 2006, at 10:55, Jeffrey Harris 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.
I'd lean towards option 1). A flat-file system is probably the
cheapest way to get a reminder widget up and running with low
resource consumption, so I'm not opposed to starting there, but I
can imagine this background process having:
- a hotkey that essentially pops up the current Chandler preview area,
- a quick-entry widget, or
- maybe just run the appropriate server to accept quick-entries from
XML-RPC
Since we're already committed to handling merges well, it seems
like we might as well take advantage of the existing investment...
Yeah, I'm inclined to go this way, too. At least, I think I could
write the periodic repository refresh code faster than I can write
the flat-file system. Hopefully, no Chandler user will be crazy
enough to try run the app on some wacky lock-free filesystem :0.
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
