diff options
| author | David Schlachter <t480-debian-git@schlachter.ca> | 2025-11-10 00:24:57 -0500 |
|---|---|---|
| committer | David Schlachter <t480-debian-git@schlachter.ca> | 2025-11-10 00:24:57 -0500 |
| commit | 276f6d2a67b74476ea7bd559ca9ccf738c6d73bf (patch) | |
| tree | ccc9403c939b406bee3f7021b4a3586d7cf2170d /README.md | |
| parent | 41300522d52a0aba6895f671088822a8d326d152 (diff) | |
Add future work to readme
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 12 |
1 files changed, 11 insertions, 1 deletions
@@ -1,5 +1,7 @@ # Todoist Repeater +## Background + I use Todoist as my todo app. I add tasks to my Inbox, sorted descending by date added. However, repeating tasks in Todoist don't work with my workflow: they stay in a fixed position in the list, and just refresh the due date. What I want is a task that appears on a given interval, disappears when it's completed, and, when it's time to do it again, reappears at the top of the list. @@ -13,6 +15,8 @@ Some examples of tasks that I want to recurr in this way: - every six months, wash and condition the leather sofa - every three months, do a reflection on how I'm feeling about work +## Design + The idea for this program is to: - have a list of tasks that specifies the task name and the recurrence (interval, start and end date) @@ -43,4 +47,10 @@ At program start, and every minute thereafter: - if we have not seen it, add the line to the hash of seen lines; then, add it to the scheduler - if there were any lines that we did not see during this read of the file, but that we saw previously, remove them from the scheduler -The lines will be formatted like a cron file, but instead of a command, we will simply have the name of the task to be created.
\ No newline at end of file +The lines will be formatted like a cron file, but instead of a command, we will simply have the name of the task to be created. + +## Future work + +It turns out jobs can be added AND removed by an ID that is returned from the Add function. It could be interesting to add/remove based on the last seen map (with the job IDs), instead of completely recreating all the jobs if the input file changes. + +We should probably retry failed network requests. It would not be great to have a temporary connectivity issue lead to missing an important task! |
