I'm starting to notice some existing metaphors that apply eerily well to Da Vinci Bot's structure:

File system metaphor

Da Vinci Bot Ideas are basically a combination of files and directories in a traditional file system. I can actually envision modeling them as such, and gaining access to operating system utilities for planned features such as searching the Idea tree for keywords. However lookup by ID would be slower (it's worth asking if lookup by ID is actually all that useful for Da Vinci Bot, though).

Version control metaphor

As mentioned in #6, utilities such as forking a Da Vinci file could come in handy. Also, if I continue to store Da Vinci files in json, they could actually be committed to a repo and this would solve web synchronization (#1).

This is a common problem with project management/note taking apps: if the user manages to go a long time without using the app, their notes will fall out of step with projects and interests. This makes it harder to resume using the app after a long period of time. Maybe Da Vinci Bot can overcome this problem in a flexible, accessible way.

Proposal: a nuke command that saves the current tree in a separate backup file (essentially forking it) and walks the user through cutting out/tagging as outdated large swaths of nodes that have been left over. It should be quick to jump back into Da Vinci Bot with an entirely new set of concerns and get up and running without digging out from the pressure of dangling Ideas.

Jacob Kozak (W1'17): Things I would like to have in dv:

Jacob Kozak (W1'17): Readline for input so I can do ctrl-r and stuff for history search

Jacob Kozak (W1'17): Command shortcuts (first letter of the command instead of the whole word)

Jacob Kozak (W1'17): Ctrl-D should quit the whole program

Jacob Kozak (W1'17): Or rather, reading an EOF should end the program

when edit_rs launches an external editor, it issues an interrupt signal to DaVinciBot, and this gets processed by the REPL (I think). This interrupts Vim without closing Vim, causing some whacky behavior. We're gonna need to detect when interrupt signals are because of a subprocess, and in that case, don't process them the same.

Use this crate to allow optional cloud sync. https://docs.rs/s4/0.0.8/s4/
The davinci file will need to have a global config for the account and secret keys. On open/close, it will prompt a check against AWS to see if you have the latest revision. After every change (?) or on a special command it will update the cloud version

As pointed out by @hdhoang in PR #14, meta tags aren't functioning properly.

A user's Da Vinci ideas should be synchronizable across devices.

User data should be stored in an optimized database, not JSON, and only retrieved by ID when necessary, not loaded all at once.

Idea fields such as duration and progress shouldn't be hard-coded because not all Ideas will need them. For instance, an Idea could be used to store notes rather than to-do items, in which case neither will be relevant.

Rather, these fields should be stored in some kind of dynamic dictionary, and Ideas should also be allowed to select from various IsVisible() algorithms that determine whether an Idea still needs to be shown to the user under normal circumstances. (For example, one such algorithm could hide Ideas with a progress field set to 100%)